On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov [off-list ref] wrote:
On Tue, Dec 19, 2017 at 10:01 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
quoted
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 ...
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 syzkaller@googlegroups.com.
Please credit me with: Reported-by: syzbot [off-list ref]
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.
On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov [off-list ref] wrote:
On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:01 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
quoted
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 ...
Looks like a networking issue, it tried to create two sysfs directories
with the same name, which isn't a sysfs bug :)
On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:01 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
quoted
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 ...
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'
That's a wonderful filename :)
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:
Kernel panic - not syncing: panic_on_warn set ...
Yup, panic_on_warn :(
ideas to make this easier for you?
thanks,
greg k-h
On Mon, Jan 22, 2018 at 3:00 PM, Greg KH [off-list ref] wrote:
On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
quoted
On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:01 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
quoted
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 ...
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'
That's a wonderful filename :)
quoted
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
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!
On Mon, Jan 22, 2018 at 03:30:12PM +0100, Dmitry Vyukov wrote:
On Mon, Jan 22, 2018 at 3:00 PM, Greg KH [off-list ref] wrote:
quoted
On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
quoted
On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:01 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
quoted
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 ...
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'
That's a wonderful filename :)
quoted
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
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.
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
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <dvyukov@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Dmitry, does this look good to you? If so, I'll queue it up for
4.16-rc1.
On Mon, Jan 22, 2018 at 3:57 PM, Greg KH [off-list ref] wrote:
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <dvyukov@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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).
On Mon, Jan 22, 2018 at 3:45 PM, Greg KH [off-list ref] wrote:
On Mon, Jan 22, 2018 at 03:30:12PM +0100, Dmitry Vyukov wrote:
quoted
On Mon, Jan 22, 2018 at 3:00 PM, Greg KH [off-list ref] wrote:
quoted
On Mon, Jan 22, 2018 at 02:47:33PM +0100, Dmitry Vyukov wrote:
quoted
On Tue, Dec 19, 2017 at 10:06 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:03 AM, Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Dec 19, 2017 at 10:01 AM, Greg KH [off-list ref] wrote:
quoted
On Mon, Dec 18, 2017 at 08:57:01AM -0800, syzbot wrote:
quoted
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 ...
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'
That's a wonderful filename :)
quoted
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
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.
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.