[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6c58e18b-1a66-4853-af33-17bc6f9f7ebd@rowland.harvard.edu>
Date: Thu, 17 Aug 2023 10:12:52 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oneukum@...e.com>
Cc: syzbot <syzbot+d6b0b0ea0781c14b2ecf@...kaller.appspotmail.com>,
arnd@...db.de, christian.brauner@...ntu.com,
gregkh@...uxfoundation.org, hdanton@...a.com,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
mpe@...erman.id.au, oleg@...hat.com,
syzkaller-bugs@...glegroups.com, web@...kaller.appspotmail.com
Subject: Re: [syzbot] [usb?] KASAN: slab-use-after-free Write in
usb_anchor_suspend_wakeups
On Thu, Aug 17, 2023 at 02:16:26PM +0200, Oliver Neukum wrote:
> On 12.08.23 17:56, Alan Stern wrote:
> Hi,
> > The real problem seems to be some sort of race in usbtmc and the core
> > between URBs being added to an anchor, file I/O being stopped, and URBs
> > being killed or scuttled when the file is flushed.
>
> just to make sure, you think it is failing here:
>
> usb_anchor_resume_wakeups(anchor);
That's what the syzbot console log output shows in the stack dump.
> because we cannot guarantee that the anchor pointer
> is still valid,
That's my conclusion. There don't seem to be any other candidates for a
bad pointer.
> unless we refcount anchors, which would
> make embedding them impossible?
Whether the validity is ensured by refcounting or by some other
mechanism is up to the implementor (i.e., you). I'm merely trying to
restate and explain the syzbot results in terms understandable by
humans.
Alan Stern
Powered by blists - more mailing lists