Re: divide error in alauda_transport

[Alan Stern]

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