Dear developers and maintainers,
We encountered a shift-out-of-bounds bug while using our modified
Syzkaller. It is tested against linux kernel 6.9-rc1. Kernel config
and C repro are attached to this email. The UBSAN report is listed
below.
================================================================================
UBSAN: shift-out-of-bounds in /home/sy/linux-original/drivers/scsi/sg.c:1902:13
shift exponent 64 is too large for 32-bit type 'int'
CPU: 1 PID: 8078 Comm: syz-executor748 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_shift_out_of_bounds+0x24b/0x430 lib/ubsan.c:387
sg_build_indirect.cold+0x1b/0x20 drivers/scsi/sg.c:1902
sg_build_reserve+0xc4/0x180 drivers/scsi/sg.c:2012
sg_add_sfp drivers/scsi/sg.c:2194 [inline]
sg_open+0xde4/0x1810 drivers/scsi/sg.c:350
chrdev_open+0x269/0x770 fs/char_dev.c:414
do_dentry_open+0x6d3/0x18d0 fs/open.c:948
do_open fs/namei.c:3622 [inline]
path_openat+0x1e1e/0x26d0 fs/namei.c:3779
do_filp_open+0x1c9/0x410 fs/namei.c:3809
do_sys_openat2+0x160/0x1c0 fs/open.c:1437
do_sys_open fs/open.c:1452 [inline]
__do_sys_openat fs/open.c:1468 [inline]
__se_sys_openat fs/open.c:1463 [inline]
__x64_sys_openat+0x140/0x1f0 fs/open.c:1463
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f48cf37f80b
Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85
c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d
00 f0 ff ff 0f 87 91 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
RSP: 002b:00007ffd29cd7d40 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f48cf37f80b
RDX: 0000000000000041 RSI: 00007ffd29cd7dc0 RDI: 00000000ffffff9c
RBP: 00007ffd29cd7dc0 R08: 000000000000ffff R09: 00007ffd29cd7c50
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000041
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
================================================================================
If you have any questions, please contact us.
Reported by: Yue Sun <[email protected]>
Reported by: xingwei lee <[email protected]>
Best Regards,
Yue
On Mon, Mar 25, 2024 at 8:57 PM Sam Sun <[email protected]> wrote:
>
> Dear developers and maintainers,
>
> We encountered a shift-out-of-bounds bug while using our modified
> Syzkaller. It is tested against linux kernel 6.9-rc1. Kernel config
> and C repro are attached to this email. The UBSAN report is listed
> below.
>
> ================================================================================
> UBSAN: shift-out-of-bounds in /home/sy/linux-original/drivers/scsi/sg.c:1902:13
> shift exponent 64 is too large for 32-bit type 'int'
> CPU: 1 PID: 8078 Comm: syz-executor748 Not tainted 6.7.0-rc7 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106
> ubsan_epilogue lib/ubsan.c:217 [inline]
> __ubsan_handle_shift_out_of_bounds+0x24b/0x430 lib/ubsan.c:387
> sg_build_indirect.cold+0x1b/0x20 drivers/scsi/sg.c:1902
> sg_build_reserve+0xc4/0x180 drivers/scsi/sg.c:2012
> sg_add_sfp drivers/scsi/sg.c:2194 [inline]
> sg_open+0xde4/0x1810 drivers/scsi/sg.c:350
> chrdev_open+0x269/0x770 fs/char_dev.c:414
> do_dentry_open+0x6d3/0x18d0 fs/open.c:948
> do_open fs/namei.c:3622 [inline]
> path_openat+0x1e1e/0x26d0 fs/namei.c:3779
> do_filp_open+0x1c9/0x410 fs/namei.c:3809
> do_sys_openat2+0x160/0x1c0 fs/open.c:1437
> do_sys_open fs/open.c:1452 [inline]
> __do_sys_openat fs/open.c:1468 [inline]
> __se_sys_openat fs/open.c:1463 [inline]
> __x64_sys_openat+0x140/0x1f0 fs/open.c:1463
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
> RIP: 0033:0x7f48cf37f80b
> Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85
> c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d
> 00 f0 ff ff 0f 87 91 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
> RSP: 002b:00007ffd29cd7d40 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f48cf37f80b
> RDX: 0000000000000041 RSI: 00007ffd29cd7dc0 RDI: 00000000ffffff9c
> RBP: 00007ffd29cd7dc0 R08: 000000000000ffff R09: 00007ffd29cd7c50
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000041
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> </TASK>
> ================================================================================
>
> If you have any questions, please contact us.
> Reported by: Yue Sun <[email protected]>
> Reported by: xingwei lee <[email protected]>
>
> Best Regards,
> Yue
We further analyzed the root cause of this bug. In function
sg_build_indirect of drivers/scsi/sg.c, variable order of line 1900 is
calculated out using get_order(num), and num comes from
scatter_elem_sz. If scatter_elem_sz is equal or below zero, the order
returned will be 52, so that PAGE_SHIFT + order is 64, which is larger
than 32 bits int range, causing shift-out-of bound. This bug is tested
and still remains in the latest upstream linux (6.9-rc3).
If you have any questions, please contact us.
Best,
Yue
On 4/9/24 05:51, Sam Sun wrote:
> We further analyzed the root cause of this bug. In function
> sg_build_indirect of drivers/scsi/sg.c, variable order of line 1900 is
> calculated out using get_order(num), and num comes from
> scatter_elem_sz. If scatter_elem_sz is equal or below zero, the order
> returned will be 52, so that PAGE_SHIFT + order is 64, which is larger
> than 32 bits int range, causing shift-out-of bound. This bug is tested
> and still remains in the latest upstream linux (6.9-rc3).
> If you have any questions, please contact us.
Thank you for having root-caused this issue and also for having shared
your root-cause analysis. Do you perhaps plan to post a patch that fixes
this issue?
Thanks,
Bart.
On Wed, Apr 10, 2024 at 12:59 AM Bart Van Assche <[email protected]> wrote:
>
> On 4/9/24 05:51, Sam Sun wrote:
> > We further analyzed the root cause of this bug. In function
> > sg_build_indirect of drivers/scsi/sg.c, variable order of line 1900 is
> > calculated out using get_order(num), and num comes from
> > scatter_elem_sz. If scatter_elem_sz is equal or below zero, the order
> > returned will be 52, so that PAGE_SHIFT + order is 64, which is larger
> > than 32 bits int range, causing shift-out-of bound. This bug is tested
> > and still remains in the latest upstream linux (6.9-rc3).
> > If you have any questions, please contact us.
>
> Thank you for having root-caused this issue and also for having shared
> your root-cause analysis. Do you perhaps plan to post a patch that fixes
> this issue?
>
> Thanks,
>
> Bart.
>
Sure, I am glad to help! But it is my first time submitting a patch, I
need to find some instructions. I would appreciate if you could help
me out. Also, I need to double check the patch to avoid introducing a
new one. It might take some time.
Best,
Yue
On 4/10/24 6:17 PM, Sam Sun wrote:
> On Wed, Apr 10, 2024 at 12:59 AM Bart Van Assche <[email protected]> wrote:
>>
>> On 4/9/24 05:51, Sam Sun wrote:
>>> We further analyzed the root cause of this bug. In function
>>> sg_build_indirect of drivers/scsi/sg.c, variable order of line 1900 is
>>> calculated out using get_order(num), and num comes from
>>> scatter_elem_sz. If scatter_elem_sz is equal or below zero, the order
>>> returned will be 52, so that PAGE_SHIFT + order is 64, which is larger
>>> than 32 bits int range, causing shift-out-of bound. This bug is tested
>>> and still remains in the latest upstream linux (6.9-rc3).
>>> If you have any questions, please contact us.
>>
>> Thank you for having root-caused this issue and also for having shared
>> your root-cause analysis. Do you perhaps plan to post a patch that fixes
>> this issue?
>
> Sure, I am glad to help! But it is my first time submitting a patch, I
> need to find some instructions. I would appreciate if you could help
> me out. Also, I need to double check the patch to avoid introducing a
> new one. It might take some time.
The process for contributing a patch is as follows:
1. Clone the Linux kernel tree for the subsystem you want to contribute
to. For SCSI, this is the for-next branch in
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
2. Make your changes to the code.
3. Commit your changes (git commit -as), chose a patch title and explain
what has been changed and also why.
4. Convert your changes into a patch, e.g. by running this command:
git format-patch -1
5. Check the patch with scripts/checkpatch.pl.
6. Send your patch with git send-email to Martin Petersen and Cc the
linux-scsi mailing list.
More information is available here:
https://docs.kernel.org/process/submitting-patches.html
Best regards,
Bart.
On Sat, Apr 13, 2024 at 6:49 AM Bart Van Assche <[email protected]> wrote:
>
> On 4/10/24 6:17 PM, Sam Sun wrote:
> > On Wed, Apr 10, 2024 at 12:59 AM Bart Van Assche <[email protected]> wrote:
> >>
> >> On 4/9/24 05:51, Sam Sun wrote:
> >>> We further analyzed the root cause of this bug. In function
> >>> sg_build_indirect of drivers/scsi/sg.c, variable order of line 1900 is
> >>> calculated out using get_order(num), and num comes from
> >>> scatter_elem_sz. If scatter_elem_sz is equal or below zero, the order
> >>> returned will be 52, so that PAGE_SHIFT + order is 64, which is larger
> >>> than 32 bits int range, causing shift-out-of bound. This bug is tested
> >>> and still remains in the latest upstream linux (6.9-rc3).
> >>> If you have any questions, please contact us.
> >>
> >> Thank you for having root-caused this issue and also for having shared
> >> your root-cause analysis. Do you perhaps plan to post a patch that fixes
> >> this issue?
> >
> > Sure, I am glad to help! But it is my first time submitting a patch, I
> > need to find some instructions. I would appreciate if you could help
> > me out. Also, I need to double check the patch to avoid introducing a
> > new one. It might take some time.
>
> The process for contributing a patch is as follows:
> 1. Clone the Linux kernel tree for the subsystem you want to contribute
> to. For SCSI, this is the for-next branch in
> git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
> 2. Make your changes to the code.
> 3. Commit your changes (git commit -as), chose a patch title and explain
> what has been changed and also why.
> 4. Convert your changes into a patch, e.g. by running this command:
> git format-patch -1
> 5. Check the patch with scripts/checkpatch.pl.
> 6. Send your patch with git send-email to Martin Petersen and Cc the
> linux-scsi mailing list.
>
> More information is available here:
> https://docs.kernel.org/process/submitting-patches.html
>
> Best regards,
>
> Bart.
Thanks for your help! I will follow the instructions and submit the
patch as soon as possible.
Best Regards,
Yue