lkml.org 
[lkml]   [2024]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linux kernel bug] general protection fault in disable_store
On Wed, Apr 17, 2024 at 03:39:02PM +0800, Sam Sun wrote:
> On Wed, Apr 17, 2024 at 12:35 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> > It turns out that patch is no good. The reason is mentioned in the
> > changelog for commit 543d7784b07f ("USB: fix race between hub_disconnect
> > and recursively_mark_NOTATTACHED"); it says that the port devices have to
> > be removed _after_ maxchild has been set to 0.
> >
>
> I checked the commit you mentioned. Maybe your first fix is all we
> need to fix the problem? At least no race would occur for
> hdev->maxchild and usb_set_intfdata().

No, the first patch won't help, even though it passed your testing. The
race it eliminates is a harmless one -- or at least, it's harmless in
this context. If usb_hub_to_struct_hub() sees bad values for
hdev->maxchild or usb_get_intfdata(), it will simply return NULL. But
this can happen even with the first patch applied, if the user tries to
access disable_store() during the brief time between when hdev->maxchild
is set to 0 and when the port devices are removed.

The true fix is simply to check whether the return value from
usb_hub_to_struct_hub() is NULL, which is what this patch does.

> I applied this patch and it also can fix the warning. I am not sure
> which one is better.

I'm quite sure that this one is better. I will submit it shortly, with
your Tested-by:.

Thanks a lot; the work you have done on this has been a big help.

Alan Stern

\
 
 \ /
  Last update: 2024-04-17 16:24    [W:0.047 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site