On Sun, Mar 17, 2024 at 11:57:58PM +0800, xingwei lee wrote: > On Mar 17, 2024, at 23:04, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Mar 17, 2024 at 04:31:01PM +0800, xingwei lee wrote: > > Hello I found a bug in latest upstream titled "divide error in > alauda_transport", and maybe is realted with usb. > I comfired in the latest upstream the poc tree can trigger the issue. > > If you fix this issue, please add the following tag to the commit: > Reported-by: xingwei lee <xrivendell7@xxxxxxxxx> > Reported-by: yue sun <samsun1006219@xxxxxxxxx> > > kernel: upstream 9187210eee7d87eea37b45ea93454a88681894a4 > config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=1c6662240382da2 > with KASAN enabled > compiler: gcc (Debian 12.2.0-14) 12.2.0 > > divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI > CPU: 2 PID: 8229 Comm: usb-storage Not tainted 6.8.0-05202-g9187210eee7d #20 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.16.2-1.fc38 04/01/2014 > RIP: 0010:alauda_read_data drivers/usb/storage/alauda.c:954 [inline] > RIP: 0010:alauda_transport+0xcaf/0x3830 drivers/usb/storage/alauda.c:1184 > Hi Alan > > I apply your patch in my upstream commit > 9187210eee7d87eea37b45ea93454a88681894a4 > However, the poc still trigger the bug like below: > [ 146.141945][ T8215] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI > [ 146.143565][ T8215] CPU: 1 PID: 8215 Comm: usb-storage Not tainted > 6.8.0-05202-g9187210eee7d-dirty #21 > [ 146.145319][ T8215] Hardware name: QEMU Standard PC (i440FX + PIIX, > 1996), BIOS 1.16.2-1.fc38 04/01/2014 > [ 146.146720][ T8215] RIP: 0010:alauda_transport+0xc65/0x38b0 The line in your original bug report, alauda.c:954, was a call to alauda_ensure_map_for_zone(), which my patch moves to a different location so that a test for overflow can run first. It's hard to tell whether the divide error occurs before the function call, within the function, or after. Furthermore, alauda_ensure_map_for_zone() calls alauda_read_map(), and it's hard to tell if the divide error occurs before that function call or within the function. Can you try adding some pr_info() statements to those places so we can determine exactly where the error occurs? The only divisions that I see are by 2 or by uzonesize, which should always be nonzero. Maybe you can print out the value of uzonesize so we can verify this. Thanks, Alan Stern
