Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
Stack dump:
UBSAN: shift-out-of-bounds in fs/bcachefs/super-io.c:310:18
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 14408 Comm: syz-executor.3 Not tainted 6.7.0 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-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
validate_sb_layout.cold+0x1a/0x51 fs/bcachefs/super-io.c:310
bch2_read_super+0x980/0x1000 fs/bcachefs/super-io.c:786
bch2_fs_open+0x471/0x3890 fs/bcachefs/super.c:1922
bch2_mount+0x538/0x13c0 fs/bcachefs/fs.c:1863
legacy_get_tree+0x109/0x220 fs/fs_context.c:662
vfs_get_tree+0x93/0x380 fs/super.c:1771
do_new_mount fs/namespace.c:3337 [inline]
path_mount+0x679/0x1e40 fs/namespace.c:3664
do_mount fs/namespace.c:3677 [inline]
__do_sys_mount fs/namespace.c:3886 [inline]
__se_sys_mount fs/namespace.c:3863 [inline]
__x64_sys_mount+0x287/0x310 fs/namespace.c:3863
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f41e1091b3e
Code: 48 c7 c0 ff ff ff ff eb aa e8 be 0d 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f41e1d22e38 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000000005d82 RCX: 00007f41e1091b3e
RDX: 0000000020005d80 RSI: 0000000020000100 RDI: 00007f41e1d22e90
RBP: 00007f41e1d22ed0 R08: 00007f41e1d22ed0 R09: 0000000000000080
R10: 0000000000000080 R11: 0000000000000202 R12: 0000000020005d80
R13: 0000000020000100 R14: 00007f41e1d22e90 R15: 0000000020005e00
</TASK>
Thank you for taking the time to read this email and we look forward to working with you further.
On Mon, 20 May 2024 15:02:26 +0800
"Ubisectech Sirius" <[email protected]> wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
>
> Stack dump:
> UBSAN: shift-out-of-bounds in fs/bcachefs/super-io.c:310:18
> shift exponent 127 is too large for 32-bit type 'int'
> CPU: 0 PID: 14408 Comm: syz-executor.3 Not tainted 6.7.0 #2
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-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
> validate_sb_layout.cold+0x1a/0x51 fs/bcachefs/super-io.c:310
> bch2_read_super+0x980/0x1000 fs/bcachefs/super-io.c:786
> bch2_fs_open+0x471/0x3890 fs/bcachefs/super.c:1922
> bch2_mount+0x538/0x13c0 fs/bcachefs/fs.c:1863
> legacy_get_tree+0x109/0x220 fs/fs_context.c:662
> vfs_get_tree+0x93/0x380 fs/super.c:1771
> do_new_mount fs/namespace.c:3337 [inline]
> path_mount+0x679/0x1e40 fs/namespace.c:3664
> do_mount fs/namespace.c:3677 [inline]
> __do_sys_mount fs/namespace.c:3886 [inline]
> __se_sys_mount fs/namespace.c:3863 [inline]
> __x64_sys_mount+0x287/0x310 fs/namespace.c:3863
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x6f/0x77
> RIP: 0033:0x7f41e1091b3e
> Code: 48 c7 c0 ff ff ff ff eb aa e8 be 0d 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f41e1d22e38 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000000005d82 RCX: 00007f41e1091b3e
> RDX: 0000000020005d80 RSI: 0000000020000100 RDI: 00007f41e1d22e90
> RBP: 00007f41e1d22ed0 R08: 00007f41e1d22ed0 R09: 0000000000000080
> R10: 0000000000000080 R11: 0000000000000202 R12: 0000000020005d80
> R13: 0000000020000100 R14: 00007f41e1d22e90 R15: 0000000020005e00
> </TASK>
>
> Thank you for taking the time to read this email and we look forward to working with you further.
I'm not sure why this is getting Cc'd to linux-trace-kernel. That's for
anything to do with the tracing code (trace events, tracepoints, kprobes,
uprobes, function tracer etc).
What part of tracing is this for?
-- Steve
On Mon, May 20, 2024 at 10:31:53AM -0400, Steven Rostedt wrote:
> On Mon, 20 May 2024 15:02:26 +0800
> "Ubisectech Sirius" <[email protected]> wrote:
>
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
> >
> > Stack dump:
> > UBSAN: shift-out-of-bounds in fs/bcachefs/super-io.c:310:18
> > shift exponent 127 is too large for 32-bit type 'int'
> > CPU: 0 PID: 14408 Comm: syz-executor.3 Not tainted 6.7.0 #2
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-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
> > validate_sb_layout.cold+0x1a/0x51 fs/bcachefs/super-io.c:310
> > bch2_read_super+0x980/0x1000 fs/bcachefs/super-io.c:786
> > bch2_fs_open+0x471/0x3890 fs/bcachefs/super.c:1922
> > bch2_mount+0x538/0x13c0 fs/bcachefs/fs.c:1863
> > legacy_get_tree+0x109/0x220 fs/fs_context.c:662
> > vfs_get_tree+0x93/0x380 fs/super.c:1771
> > do_new_mount fs/namespace.c:3337 [inline]
> > path_mount+0x679/0x1e40 fs/namespace.c:3664
> > do_mount fs/namespace.c:3677 [inline]
> > __do_sys_mount fs/namespace.c:3886 [inline]
> > __se_sys_mount fs/namespace.c:3863 [inline]
> > __x64_sys_mount+0x287/0x310 fs/namespace.c:3863
> > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83
> > entry_SYSCALL_64_after_hwframe+0x6f/0x77
> > RIP: 0033:0x7f41e1091b3e
> > Code: 48 c7 c0 ff ff ff ff eb aa e8 be 0d 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007f41e1d22e38 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
> > RAX: ffffffffffffffda RBX: 0000000000005d82 RCX: 00007f41e1091b3e
> > RDX: 0000000020005d80 RSI: 0000000020000100 RDI: 00007f41e1d22e90
> > RBP: 00007f41e1d22ed0 R08: 00007f41e1d22ed0 R09: 0000000000000080
> > R10: 0000000000000080 R11: 0000000000000202 R12: 0000000020005d80
> > R13: 0000000020000100 R14: 00007f41e1d22e90 R15: 0000000020005e00
> > </TASK>
> >
> > Thank you for taking the time to read this email and we look forward to working with you further.
>
> I'm not sure why this is getting Cc'd to linux-trace-kernel. That's for
> anything to do with the tracing code (trace events, tracepoints, kprobes,
> uprobes, function tracer etc).
>
> What part of tracing is this for?
Everything I've seen from Ubisectech has been duplicates of stuff syzbot
found awhile ago and is already fixed.