Skip to contentSkip to conversation

WARNING in sysfs_warn_dup

PATCH In review Greg KH 2 participants 9 messages Dec 19, 2017 – Jan 22, 2018 2 messages not in the archive

Subsystems (3)
Networking Network drivers Driver core
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Greg KH

author maintainer
#1 lore raw
Quoted 20 lines · syzbot

Hello,

syzkaller hit the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.

netlink: 9 bytes leftover after parsing attributes in process `syz-executor3'.
sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly
sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly

Quoted 3 lines
WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...

Looks like a networking issue, it tried to create two sysfs directories with the same name, which isn't a sysfs bug :)

thanks,

greg k-h

A message that is not in the archive (sent off-list or not yet received): CACT4Y+ZggKsEjCRZsFPW5-7_ByBcz4G0uRdieLL==r4mLQjhFA@mail.gmail.com

#3 lore raw
Quoted 28 lines · Dmitry Vyukov
Quoted 26 lines · Greg KH
Quoted 23 lines · syzbot

Hello,

syzkaller hit the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.

netlink: 9 bytes leftover after parsing attributes in process `syz-executor3'.
sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly
sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly

WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...
Quoted 2 lines
Quoted 2 lines

Looks like a networking issue, it tried to create two sysfs directories with the same name, which isn't a sysfs bug :)

Now as plain text:

+net/core/dev.c maintainers

Let's keep the footer as well, so that people know how to handle this report:

---
This bug is generated by a dumb bot. It may contain errors. See https://goo.gl/tpsmEJ for details.
Direct all questions to [email protected].
Please credit me with: Reported-by: syzbot <[email protected]>

syzbot will keep track of this bug report.
Once a fix for this bug is merged into any tree, reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug report.
Note: all commands must start from beginning of the line in the email body.

#4 lore raw
Quoted 29 lines · Dmitry Vyukov
Quoted 28 lines · Dmitry Vyukov
Quoted 26 lines · Greg KH
Quoted 23 lines · syzbot

Hello,

syzkaller hit the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.

netlink: 9 bytes leftover after parsing attributes in process `syz-executor3'.
sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly
sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly

WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

Looks like a networking issue, it tried to create two sysfs directories with the same name, which isn't a sysfs bug :)

Now as plain text:

+net/core/dev.c maintainers

Also happens for wiphy_register (on upstream
a8750ddca918032d6349adbf9a4b6555e7db20da):

------------[ cut here ]------------
sysfs: cannot create duplicate filename
'/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá   ×ÝÊmô Be'
WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 8233 Comm: syz-executor7 Not tainted 4.15.0-rc8+ #263
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x194/0x257 lib/dump_stack.c:53
 panic+0x1e4/0x41c kernel/panic.c:183
 __warn+0x1dc/0x200 kernel/panic.c:547
 report_bug+0x211/0x2d0 lib/bug.c:184
 fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
 fixup_bug arch/x86/kernel/traps.c:247 [inline]
 do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
 invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1085
RIP: 0010:sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30
RSP: 0018:ffff8801d00def20 EFLAGS: 00010286
RAX: dffffc0000000008 RBX: ffff8801c4ff2ac0 RCX: ffffffff8159dade
RDX: 000000000000cb4f RSI: ffffc9000192b000 RDI: ffff8801d00dec28
RBP: ffff8801d00def38 R08: 1ffff1003a01bd61 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801d976fa80
R13: ffff8801d833e380 R14: 0000000000000001 R15: ffffffffffffffef
 sysfs_do_create_link_sd.isra.2+0xf3/0x110 fs/sysfs/symlink.c:51
 sysfs_do_create_link fs/sysfs/symlink.c:80 [inline]
 sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:92
 device_add_class_symlinks drivers/base/core.c:1603 [inline]
 device_add+0x74a/0x1650 drivers/base/core.c:1801
 wiphy_register+0x1468/0x2050 net/wireless/core.c:800
 ieee80211_register_hw+0x1162/0x3100 net/mac80211/main.c:1038
 mac80211_hwsim_new_radio+0x1b2e/0x2b90
drivers/net/wireless/mac80211_hwsim.c:2700
 hwsim_new_radio_nl+0x5b7/0x7c0 drivers/net/wireless/mac80211_hwsim.c:3152
 genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
 genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
 netlink_rcv_skb+0x224/0x470 net/netlink/af_netlink.c:2408
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
 netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
 netlink_unicast+0x4ee/0x700 net/netlink/af_netlink.c:1301
 netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
 sock_sendmsg_nosec net/socket.c:638 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:648
 ___sys_sendmsg+0x767/0x8b0 net/socket.c:2028
 __sys_sendmsg+0xe5/0x210 net/socket.c:2062
 SYSC_sendmsg net/socket.c:2073 [inline]
 SyS_sendmsg+0x2d/0x50 net/socket.c:2069
 entry_SYSCALL_64_fastpath+0x29/0xa0

If you fix this, please add:

Reported-by syzbot+1fdad4e2731bf0c1bc19953ccc5061237ec92783@syzkaller.appspotmail.com

tag. It will help syzbot understand when the bug is fixed.

author maintainer
#5 lore raw
Quoted 39 lines · Dmitry Vyukov
Quoted 29 lines · Dmitry Vyukov
Quoted 28 lines · Dmitry Vyukov
Quoted 26 lines · Greg KH
Quoted 23 lines · syzbot

Hello,

syzkaller hit the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.

netlink: 9 bytes leftover after parsing attributes in process `syz-executor3'.
sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly
sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly

WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

Looks like a networking issue, it tried to create two sysfs directories with the same name, which isn't a sysfs bug :)

Now as plain text:

+net/core/dev.c maintainers

Quoted 6 lines

Also happens for wiphy_register (on upstream
a8750ddca918032d6349adbf9a4b6555e7db20da):

------------[ cut here ]------------
sysfs: cannot create duplicate filename

'/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá ×ÝÊmô Be'

That's a wonderful filename :)

Quoted 2 lines
WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30

As this is just sysfs saying "Hey dummy, you are trying to do something foolish here", what would be the better thing for it to do?

Just printk(KERN_WARNING...) and then dump the stack?

It seems the WARN_ON() that is currently being used is being treated as an "error" by your testing, when really it isn't, unless the caller can not handle the error being passed back up to it by the sysfs core. Which it should, but I don't think you are even giving it the chance as you are:

Quoted 1 line
Kernel panic - not syncing: panic_on_warn set ...

Yup, panic_on_warn :(

ideas to make this easier for you?

thanks,

greg k-h

#6 lore raw
Quoted 63 lines · Greg KH
Quoted 39 lines · Dmitry Vyukov
Quoted 29 lines · Dmitry Vyukov
Quoted 28 lines · Dmitry Vyukov
Quoted 26 lines · Greg KH
Quoted 23 lines · syzbot

Hello,

syzkaller hit the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.

netlink: 9 bytes leftover after parsing attributes in process `syz-executor3'.
sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly
sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly

WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

Looks like a networking issue, it tried to create two sysfs directories with the same name, which isn't a sysfs bug :)

Now as plain text:

+net/core/dev.c maintainers

Quoted 6 lines

Also happens for wiphy_register (on upstream
a8750ddca918032d6349adbf9a4b6555e7db20da):

------------[ cut here ]------------
sysfs: cannot create duplicate filename

'/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá ×ÝÊmô Be'

That's a wonderful filename :)

Quoted 2 lines
WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30

As this is just sysfs saying "Hey dummy, you are trying to do something foolish here", what would be the better thing for it to do?

Just printk(KERN_WARNING...) and then dump the stack?

It seems the WARN_ON() that is currently being used is being treated as an "error" by your testing, when really it isn't, unless the caller can not handle the error being passed back up to it by the sysfs core. Which it should, but I don't think you are even giving it the chance as you are:

Quoted 5 lines
Quoted 1 line
Kernel panic - not syncing: panic_on_warn set ...

Yup, panic_on_warn :(

ideas to make this easier for you?

pr_warn or pr_warn_once (optionally followed by dump_stack) would work for syzbot.

Thanks!

author maintainer
#7 lore raw
Quoted 66 lines · Dmitry Vyukov
Quoted 65 lines · Greg KH
Quoted 39 lines · Dmitry Vyukov
Quoted 29 lines · Dmitry Vyukov
Quoted 28 lines · Dmitry Vyukov
Quoted 26 lines · Greg KH
Quoted 23 lines · syzbot

Hello,

syzkaller hit the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.

netlink: 9 bytes leftover after parsing attributes in process `syz-executor3'.
sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly
sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly

WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

Looks like a networking issue, it tried to create two sysfs directories with the same name, which isn't a sysfs bug :)

Now as plain text:

+net/core/dev.c maintainers

Quoted 6 lines

Also happens for wiphy_register (on upstream
a8750ddca918032d6349adbf9a4b6555e7db20da):

------------[ cut here ]------------
sysfs: cannot create duplicate filename

'/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá ×ÝÊmô Be'

That's a wonderful filename :)

Quoted 2 lines
WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30

As this is just sysfs saying "Hey dummy, you are trying to do something foolish here", what would be the better thing for it to do?

Just printk(KERN_WARNING...) and then dump the stack?

It seems the WARN_ON() that is currently being used is being treated as an "error" by your testing, when really it isn't, unless the caller can not handle the error being passed back up to it by the sysfs core. Which it should, but I don't think you are even giving it the chance as you are:

Quoted 1 line
Kernel panic - not syncing: panic_on_warn set ...
Quoted 7 lines
Quoted 3 lines

Yup, panic_on_warn :(

ideas to make this easier for you?

pr_warn or pr_warn_once (optionally followed by dump_stack) would work for syzbot.

This shouldn't be a _once() call, as it is called by things all over the kernel, all with unique paths.

I'll go make up a patch for this, thanks.

greg k-h

#8 lore raw
Quoted 72 lines · Greg KH
Quoted 71 lines · Dmitry Vyukov
Quoted 68 lines · Greg KH
Quoted 39 lines · Dmitry Vyukov
Quoted 29 lines · Dmitry Vyukov
Quoted 28 lines · Dmitry Vyukov
Quoted 26 lines · Greg KH
Quoted 23 lines · syzbot

Hello,

syzkaller hit the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.

netlink: 9 bytes leftover after parsing attributes in process `syz-executor3'.
sg_write: data in/out 822404280/197 bytes for SCSI command 0x12-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly
sg_write: data in/out 262364/161 bytes for SCSI command 0xff-- guessing data in;
program syz-executor0 not setting count and/or reply_len properly

WARNING: CPU: 1 PID: 22282 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x80
fs/sysfs/dir.c:30
Kernel panic - not syncing: panic_on_warn set ...
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

Looks like a networking issue, it tried to create two sysfs directories with the same name, which isn't a sysfs bug :)

Now as plain text:

+net/core/dev.c maintainers

Quoted 6 lines

Also happens for wiphy_register (on upstream
a8750ddca918032d6349adbf9a4b6555e7db20da):

------------[ cut here ]------------
sysfs: cannot create duplicate filename

'/class/ieee80211/š§"­ût{§Ô­ðô Š!× ž 7… Š†õiùS6 È< »þ {_CK5äá ×ÝÊmô Be'

That's a wonderful filename :)

Quoted 2 lines
WARNING: CPU: 1 PID: 8233 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x7e/0xa0 fs/sysfs/dir.c:30

As this is just sysfs saying "Hey dummy, you are trying to do something foolish here", what would be the better thing for it to do?

Just printk(KERN_WARNING...) and then dump the stack?

It seems the WARN_ON() that is currently being used is being treated as an "error" by your testing, when really it isn't, unless the caller can not handle the error being passed back up to it by the sysfs core. Which it should, but I don't think you are even giving it the chance as you are:

Quoted 1 line
Kernel panic - not syncing: panic_on_warn set ...

Yup, panic_on_warn :(

ideas to make this easier for you?

Quoted 7 lines
Quoted 2 lines

pr_warn or pr_warn_once (optionally followed by dump_stack) would work for syzbot.

This shouldn't be a _once() call, as it is called by things all over the kernel, all with unique paths.

I'll go make up a patch for this, thanks.

#syz fix: sysfs: turn WARN() into pr_warn()

author maintainer
#9 lore raw

PATCH 1/1 sysfs: turn WARN() into pr_warn()

In reply to Dmitry Vyukov

From: Greg Kroah-Hartman <[email protected]>

It's not good to crash the machine if panic_on_warn() is set just because someone made a stupid mistake of trying to create a sysfs file with the same name of an existing one. This makes the automated testing tools a lot harder to find the real bugs in the kernel.

So just print a warning out and dump the stack to get the attention of the developer that they did something foolish. Then keep on trucking, as this should not be a fatal error at all.

Reported-by Dmitry Vyukov <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>

---

Dmitry, does this look good to you? If so, I'll queue it up for 4.16-rc1.

fs/sysfs/dir.c +3 -2
index 2b67bda2021b..3a36a48a4b3f 100644
@@ -10,6 +10,7 @@
  * Please see Documentation/filesystems/sysfs.txt for more information.
  */
 
+#define pr_fmt(fmt)	"sysfs: " fmt
 #undef DEBUG
 
 #include <linux/fs.h>

@@ -27,8 +28,8 @@ void sysfs_warn_dup(struct kernfs_node *parent, const char *name)
 	if (buf)
 		kernfs_path(parent, buf, PATH_MAX);
 
-	WARN(1, KERN_WARNING "sysfs: cannot create duplicate filename '%s/%s'\n",
-	     buf, name);
+	pr_warn("cannot create duplicate filename '%s/%s'\n", buf, name);
+	dump_stack();
 
 	kfree(buf);
 }
#10 lore raw

Re: [PATCH] sysfs: turn WARN() into pr_warn()

Quoted 11 lines · Greg KH

From: Greg Kroah-Hartman <[email protected]>

It's not good to crash the machine if panic_on_warn() is set just because someone made a stupid mistake of trying to create a sysfs file with the same name of an existing one. This makes the automated testing tools a lot harder to find the real bugs in the kernel.

So just print a warning out and dump the stack to get the attention of the developer that they did something foolish. Then keep on trucking, as this should not be a fatal error at all.

Quoted 6 lines
Reported-by Dmitry Vyukov <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>

---

Dmitry, does this look good to you? If so, I'll queue it up for 4.16-rc1.

Perfect! Looks good. syzbot reacts on "WARNING:" string (+ if kernel panic due to panic_on_warn that's also obviously a problem).

Quoted 23 lines
fs/sysfs/dir.c +3 -2
index 2b67bda2021b..3a36a48a4b3f 100644
@@ -10,6 +10,7 @@
  * Please see Documentation/filesystems/sysfs.txt for more information.
  */
 
+#define pr_fmt(fmt)    "sysfs: " fmt
 #undef DEBUG
 
 #include <linux/fs.h>

@@ -27,8 +28,8 @@ void sysfs_warn_dup(struct kernfs_node *parent, const char *name)
        if (buf)
                kernfs_path(parent, buf, PATH_MAX);
 
-       WARN(1, KERN_WARNING "sysfs: cannot create duplicate filename '%s/%s'\n",
-            buf, name);
+       pr_warn("cannot create duplicate filename '%s/%s'\n", buf, name);
+       dump_stack();
 
        kfree(buf);
 }