[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <34123da4-56ca-4ecf-ae38-71dc1e59109e@rowland.harvard.edu>
Date: Thu, 3 Jul 2025 10:51:59 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Manas <manas18244@...td.ac.in>
Cc: Hillf Danton <hdanton@...a.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Pete Zaitcev <zaitcev@...hat.com>,
Paolo Abeni <paolo.abeni@...il.it>, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
syzbot+86b6d7c8bcc66747c505@...kaller.appspotmail.com
Subject: Re: [PATCH] usbmon: Fix out-of-bounds read in mon_copy_to_buff
On Thu, Jul 03, 2025 at 11:10:14AM +0530, Manas wrote:
> On 03.07.2025 07:12, Greg Kroah-Hartman wrote:
> > On Thu, Jul 03, 2025 at 02:57:40AM +0530, Manas Gupta via B4 Relay wrote:
> > > From: Manas Gupta <manas18244@...td.ac.in>
> > >
> > > memcpy tries to copy buffer 'from' when it is empty. This leads to
> > > out-of-bounds crash.
> >
> > What exactly is the "crash" that you are seeing? What is reporting it,
> > and how?
> >
> Hi Greg and Alan,
>
> I ran the reproducer[1] on my machine and got the following stacktrace.
>
> ```
> [ 41.601410][ T769] ==================================================================
> [ 41.601908][ T769] BUG: KASAN: slab-out-of-bounds in mon_copy_to_buff+0xc6/0x180
> [ 41.602405][ T769] Read of size 832 at addr ffff888043ee6081 by task kworker/0:2/769
> [ 41.602898][ T769]
> ```
>
> which led me on a different path. I assumed that out-of-bounds was occuring in
> `mon_copy_to_buff` without realizing it may be the caller at fault, as Alan
> pointed out in his feedback.
>
> I now notice that my stacktrace is also slightly different (or rather
> incomplete) as compared to the syzkaller report which says
>
> ```
> BUG: KASAN: slab-out-of-bounds in mon_copy_to_buff drivers/usb/mon/mon_bin.c:252 [inline]
> BUG: KASAN: slab-out-of-bounds in mon_bin_get_data drivers/usb/mon/mon_bin.c:420 [inline]
> BUG: KASAN: slab-out-of-bounds in mon_bin_event+0x1211/0x2250 drivers/usb/mon/mon_bin.c:606
> Read of size 832 at addr ffff88802888f1e1 by task kworker/0:2/979
> ```
>
> where it does mention that the issue is in the caller. The caller must ensure
> the correctness of write buffer.
>
> Also, Hillf has produced a patch [2] which looks better than mine.
>
>
> [1] https://syzkaller.appspot.com/text?tag=ReproC&x=1770d770580000
> [2] https://lore.kernel.org/all/20250703043448.2287-1-hdanton@sina.com/
Hillf's patch isn't right either. The problem is that
mon_copy_to_buff() is being called with invalid arguments. The proper
fix is not to check for bad arguments but rather to adjust the code that
computes the bad argument, which in this case is either mon_bin_event()
or mon_bin_get_data().
mon_bin_event() goes through a fairly long preparation, and it may
calculate length incorrectly, although at the moment I don't see how.
mon_bin_get_data() seems to be pretty straightforward.
I would start by figuring out which pathway is involved in the error and
logging the incorrect values to see where they come from.
Alan Stern
Powered by blists - more mailing lists