From: Alan Stern <stern@rowland.harvard.edu>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: syzbot <syzbot+dd3c97de244683533381@syzkaller.appspotmail.com>,
gregkh@linuxfoundation.org, hdanton@sina.com, lenb@kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
rafael.j.wysocki@intel.com, rafael@kernel.org, rjw@rjwysocki.net,
syzkaller-bugs@googlegroups.com, linux-usb@vger.kernel.org
Subject: Re: [syzbot] general protection fault in __device_attach
Date: Fri, 3 Jun 2022 11:42:19 -0400 [thread overview]
Message-ID: <Ypor265BTdnmgwpM@rowland.harvard.edu> (raw)
In-Reply-To: <YpnqpMYcokTwCB6u@smile.fi.intel.com>
On Fri, Jun 03, 2022 at 02:04:04PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 03, 2022 at 03:02:07AM -0700, syzbot wrote:
> > syzbot has bisected this issue to:
> >
> > commit a9c4cf299f5f79d5016c8a9646fa1fc49381a8c1
> > Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Date: Fri Jun 18 13:41:27 2021 +0000
> >
> > ACPI: sysfs: Use __ATTR_RO() and __ATTR_RW() macros
>
> Hmm... It's not obvious at all how this change can alter the behaviour so
> drastically. device_add() is called from USB core with intf->dev.name == NULL
> by some reason. A-ha, seems like fault injector, which looks like
>
> dev_set_name(&intf->dev, "%d-%s:%d.%d", dev->bus->busnum,
> dev->devpath, configuration, ifnum);
>
> missed the return code check.
>
> But I'm not familiar with that code at all, adding Linux USB ML and Alan.
I can't see any connection between this bug and acpi/sysfs.c. Is it a
bad bisection?
It looks like you're right about dev_set_name() failing. In fact, the
kernel appears to be littered with calls to that routine which do not
check the return code (the entire subtree below drivers/usb/ contains
only _one_ call that does check the return code!). The function doesn't
have any __must_check annotation, and its kerneldoc doesn't mention the
return code or the possibility of a failure.
Apparently the assumption is that if dev_set_name() fails then
device_add() later on will also fail, and the problem will be detected
then.
So now what should happen when device_add() for an interface fails in
usb_set_configuration()? I guess the interface should be deleted;
otherwise we have the possibility that people might still try to access
it via usbfs, as in the syzbot test run. Same goes for the
of_device_is_available() check.
Fixing that will be a little painful. Right now there are plenty of
places in the USB core that aren't prepared to cope with a non-existent
interface.
Alan Stern
next prev parent reply other threads:[~2022-06-03 15:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-14 8:46 [syzbot] general protection fault in __device_attach syzbot
2022-06-02 19:49 ` syzbot
2022-06-03 10:02 ` syzbot
2022-06-03 11:04 ` Andy Shevchenko
2022-06-03 15:42 ` Alan Stern [this message]
2022-06-03 15:52 ` Greg KH
2022-06-03 16:03 ` Alan Stern
2022-06-03 16:11 ` Greg KH
2022-06-03 16:27 ` Alan Stern
2022-06-04 8:32 ` Dmitry Vyukov
2022-06-06 12:38 ` Dan Carpenter
2022-06-07 7:15 ` Dmitry Vyukov
2022-06-08 3:25 ` Matthew Wilcox
2022-06-08 8:20 ` Dmitry Vyukov
2022-06-08 8:24 ` Dmitry Vyukov
2024-01-10 13:12 ` [syzbot] [kernel?] " syzbot
[not found] <20220603033532.5154-1-hdanton@sina.com>
2022-06-03 3:55 ` [syzbot] " syzbot
[not found] <20220603074439.5255-1-hdanton@sina.com>
2022-06-03 10:41 ` syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ypor265BTdnmgwpM@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=andriy.shevchenko@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdanton@sina.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=syzbot+dd3c97de244683533381@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.