Message-ID: <848a12a4-7713-4550-be8c-3d63198ea4f0.bugreport@valiantsec.com>
Date: Wed, 04 Sep 2024 14:42:25 +0800
From: "Ubisectech Sirius" <bugreport@...iantsec.com>
To: "Ryusuke Konishi" <konishi.ryusuke@...il.com>,
  "Ubisectech Sirius Team" <bugreport@...iantsec.com>
Cc: "linux-kernel" <linux-kernel@...r.kernel.org>
Subject: 回复：general protection fault in touch_buffer

>On Wed, Sep 4, 2024 at 11:05 AM Ubisectech Sirius wrote:
>>
>> Hello.
>> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.11.0-rc2-g6a0e38264012. Attached to the email were a PoC file of the issue.
>>
>> Stack dump:
>>
> >Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
> >KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
> >CPU: 0 UID: 0 PID: 14256 Comm: syz.1.435 Not tainted 6.11.0-rc2-g6a0e38264012 #49
> >Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> >RIP: 0010:perf_trace_block_buffer+0x232/0x590 include/trace/events/block.h:24
> >Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 5f 02 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 56 30 48 8d 7a 34 48 89 f9 48 c1 e9 03 <0f> b6 0c 01 48 89 f8 83 e0 07 83 c0 03 38 c8 7c 08 84 c9 0f 85 9c
> >RSP: 0018:ffffc90001957818 EFLAGS: 00010207
> >RAX: dffffc0000000000 RBX: ffffe8ffad633a98 RCX: 0000000000000006
> >RDX: 0000000000000000 RSI: 1ffff110058c6f97 RDI: 0000000000000034
> >RBP: ffffc900019578d8 R08: 0000000000000004 R09: 0000000000000004
> >R10: ffffe8ffad6ba000 R11: 0000000000000001 R12: 1ffff9200032af06
> >R13: ffffffff8e3a3fe0 R14: ffff88801fb7e2b8 R15: ffffc900019578b0
> >FS:  00007f6a432a0640(0000) GS:ffff88802c600000(0000) knlGS:0000000000000000
> >CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >CR2: 00005614bbc3d038 CR3: 000000004c664000 CR4: 0000000000750ef0
> >DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >PKRU: 55555554
> >Call Trace:
> > <TASK>
> > trace_block_touch_buffer include/trace/events/block.h:54 [inline]
> > touch_buffer+0x178/0x250 fs/buffer.c:64
> > __nilfs_get_folio_block fs/nilfs2/page.c:42 [inline]
> > nilfs_grab_buffer+0x1bb/0x380 fs/nilfs2/page.c:61
> > nilfs_mdt_submit_block+0xa4/0x870 fs/nilfs2/mdt.c:121
> > nilfs_mdt_read_block+0x92/0x3c0 fs/nilfs2/mdt.c:176
>>  nilfs_mdt_get_block+0xd2/0xaa0 fs/nilfs2/mdt.c:251
>>  nilfs_cpfile_get_checkpoint_block fs/nilfs2/cpfile.c:139 [inline]
>>  nilfs_cpfile_set_snapshot fs/nilfs2/cpfile.c:763 [inline]
>>  nilfs_cpfile_change_cpmode+0x19f/0x1b70 fs/nilfs2/cpfile.c:1055
>>  nilfs_ioctl_change_cpmode fs/nilfs2/ioctl.c:209 [inline]
>>  nilfs_ioctl+0x64f/0x1720 fs/nilfs2/ioctl.c:1278
>>  vfs_ioctl fs/ioctl.c:51 [inline]
>>  __do_sys_ioctl fs/ioctl.c:907 [inline]
>>  __se_sys_ioctl fs/ioctl.c:893 [inline]
>>  __x64_sys_ioctl+0x1a1/0x210 fs/ioctl.c:893
>>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>  do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83
>>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>> RIP: 0033:0x7f6a4259712d
>> Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
>> RSP: 002b:00007f6a4329ff98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
>> RAX: ffffffffffffffda RBX: 00007f6a42735f80 RCX: 00007f6a4259712d
>> RDX: 0000000020000080 RSI: 0000000040106e80 RDI: 000000000000000c
>> RBP: 00007f6a4261bd8a R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>> R13: 0000000000000000 R14: 00007f6a42735f80 R15: 00007f6a43280000
>>  </TASK>
>> Modules linked in:
>> ---[ end trace 0000000000000000 ]---
>> RIP: 0010:perf_trace_block_buffer+0x232/0x590 include/trace/events/block.h:24
>> Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 5f 02 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 56 30 48 8d 7a 34 48 89 f9 48 c1 e9 03 <0f> b6 0c 01 48 89 f8 83 e0 07 83 c0 03 38 c8 7c 08 84 c9 0f 85 9c
>> RSP: 0018:ffffc90001957818 EFLAGS: 00010207
>> RAX: dffffc0000000000 RBX: ffffe8ffad633a98 RCX: 0000000000000006
>> RDX: 0000000000000000 RSI: 1ffff110058c6f97 RDI: 0000000000000034
>> RBP: ffffc900019578d8 R08: 0000000000000004 R09: 0000000000000004
>> R10: ffffe8ffad6ba000 R11: 0000000000000001 R12: 1ffff9200032af06
>> R13: ffffffff8e3a3fe0 R14: ffff88801fb7e2b8 R15: ffffc900019578b0
>> FS:  00007f6a432a0640(0000) GS:ffff88802c600000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00005614bbc3d038 CR3: 000000004c664000 CR4: 0000000000750ef0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> PKRU: 55555554
>> ----------------
>> Code disassembly (best guess):
>>    0:   48 89 fa                mov    %rdi,%rdx
>>    3:   48 c1 ea 03             shr    $0x3,%rdx
>>    7:   80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)
>>    b:   0f 85 5f 02 00 00       jne    0x270
>>   11:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
>>   18:   fc ff df
>>   1b:   49 8b 56 30             mov    0x30(%r14),%rdx
>>   1f:   48 8d 7a 34             lea    0x34(%rdx),%rdi
>>   23:   48 89 f9                mov    %rdi,%rcx
>>   26:   48 c1 e9 03             shr    $0x3,%rcx
>> * 2a:   0f b6 0c 01             movzbl (%rcx,%rax,1),%ecx <-- trapping instruction
>>   2e:   48 89 f8                mov    %rdi,%rax
>>   31:   83 e0 07                and    $0x7,%eax
>>   34:   83 c0 03                add    $0x3,%eax
>>   37:   38 c8                   cmp    %cl,%al
>>   39:   7c 08                   jl     0x43
>>   3b:   84 c9                   test   %cl,%cl
>>   3d:   0f                      .byte 0xf
>>   3e:   85                      .byte 0x85
>>   3f:   9c                      pushf
>>
>> Thank you for taking the time to read this email and we look forward to working with you further.

>Thanks for reporting.

>The relevant part of the code looks normal.  The NULL pointer
>dereference may be due to the buffer head list being broken elsewhere.

>I was unable to reproduce this issue with the attached poc program,
>but since this seems to be a non-trivial issue, I think the key to
>debugging is to establish a reproducible environment.
>Do we need to use some special kconfig setting?  Or is the probability
>of reproduction low?

>Regards,
>Ryusuke Konishi

Hi.
     I have tested it several times on the latest version of Linux system and it can trigger the issue every time. My configuration file has been sent to you as an attachment.


Download attachment ".config" of type "application/octet-stream" (261121 bytes)

Download attachment "poc.c" of type "application/octet-stream" (39203 bytes)

Powered by blists - more mailing lists