Bug: slab-out-of-bounds Write in __bh_read

Bug: slab-out-of-bounds Write in __bh_read

[Kun Hu]

Hello,

When using our customized fuzzer tool to fuzz the latest Linux kernel, the following crash
was triggered.

HEAD commit: fc033cf25e612e840e545f8d5ad2edd6ba613ed5
git tree: upstream
Console output: https://drive.google.com/file/d/1-YGytaKuh9M4hI6x27YjsE0vSyRFngf5/view?usp=sharing
Kernel config: https://drive.google.com/file/d/1n2sLNg-YcIgZqhhQqyMPTDWM_N1Pqz73/view?usp=sharing
C reproducer: /
Syzlang reproducer: /

We found an issue in the __bh_read function at line 3086, where a slab-out-of-bounds error was reported. While the BUG_ON check ensures that bh is locked, I suspect it’s possible that bh might have been released prior to the call to __bh_read. This could result in accessing invalid memory, ultimately triggering the reported issue.

Unfortunately, We can’t get stable reproducers yet. Could you please help check if this needs to be addressed?

If you fix this issue, please add the following tag to the commit:
Reported-by: Kun Hu <huk23@m.fudan.edu.cn>, Jiaji Qin <jjtan24@m.fudan.edu.cn>


==================================================================
BUG: KASAN: slab-out-of-bounds in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
BUG: KASAN: slab-out-of-bounds in atomic_inc include/linux/atomic/atomic-instrumented.h:435 [inline]
BUG: KASAN: slab-out-of-bounds in get_bh include/linux/buffer_head.h:296 [inline]
BUG: KASAN: slab-out-of-bounds in __bh_read+0x6f/0x1f0 fs/buffer.c:3086
Write of size 4 at addr ff110000026598e0 by task syz.2.15/1705

CPU: 2 UID: 0 PID: 1705 Comm: syz.2.15 Not tainted 6.13.0-rc5 #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:94 [inline]
 dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xcf/0x5f0 mm/kasan/report.c:489
 kasan_report+0x93/0xc0 mm/kasan/report.c:602
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0xf6/0x1b0 mm/kasan/generic.c:189
 instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
 atomic_inc include/linux/atomic/atomic-instrumented.h:435 [inline]
 get_bh include/linux/buffer_head.h:296 [inline]
 __bh_read+0x6f/0x1f0 fs/buffer.c:3086
 bh_read_nowait include/linux/buffer_head.h:442 [inline]
 __block_write_begin_int+0x156d/0x18c0 fs/buffer.c:2145
 iomap_write_begin+0x581/0x18d0 fs/iomap/buffered-io.c:827
 iomap_write_iter fs/iomap/buffered-io.c:955 [inline]
 iomap_file_buffered_write+0x402/0xbe0 fs/iomap/buffered-io.c:1039
 gfs2_file_buffered_write+0x40b/0xb10 fs/gfs2/file.c:1060
 gfs2_file_write_iter+0x6c9/0x1080 fs/gfs2/file.c:1164
 new_sync_write fs/read_write.c:586 [inline]
 vfs_write fs/read_write.c:679 [inline]
 vfs_write+0xb9b/0x10f0 fs/read_write.c:659
 ksys_write+0x122/0x240 fs/read_write.c:731
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f65c364471d
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 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f65c2297ba8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f65c3806f80 RCX: 00007f65c364471d
RDX: 0000000000001006 RSI: 0000000020001240 RDI: 0000000000000007
RBP: 00007f65c36b9425 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f65c3806f8c R14: 00007f65c3807018 R15: 00007f65c2297d40
 </TASK>

Allocated by task 1705:
 kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __do_kmalloc_node mm/slub.c:4298 [inline]
 __kmalloc_noprof+0x1ef/0x570 mm/slub.c:4310
 kmalloc_noprof include/linux/slab.h:905 [inline]
 kzalloc_noprof include/linux/slab.h:1037 [inline]
 ifs_alloc+0x1c9/0x400 fs/iomap/buffered-io.c:202
 __iomap_write_begin fs/iomap/buffered-io.c:707 [inline]
 iomap_write_begin+0xa54/0x18d0 fs/iomap/buffered-io.c:829
 iomap_write_iter fs/iomap/buffered-io.c:955 [inline]
 iomap_file_buffered_write+0x402/0xbe0 fs/iomap/buffered-io.c:1039
 gfs2_file_buffered_write+0x40b/0xb10 fs/gfs2/file.c:1060
 gfs2_file_write_iter+0x6c9/0x1080 fs/gfs2/file.c:1164
 new_sync_write fs/read_write.c:586 [inline]
 vfs_write fs/read_write.c:679 [inline]
 vfs_write+0xb9b/0x10f0 fs/read_write.c:659
 ksys_write+0x122/0x240 fs/read_write.c:731
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ff11000002659880
 which belongs to the cache kmalloc-96 of size 96
The buggy address is located 16 bytes to the right of
 allocated 80-byte region [ff11000002659880, ff110000026598d0)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2659
anon flags: 0x100000000000000(node=0|zone=1)
page_type: f5(slab)
raw: 0100000000000000 ff1100000103c280 ffd40000010501c0 dead000000000005
raw: 0000000000000000 0000000000200020 00000001f5000000 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ff11000002659780: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
 ff11000002659800: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
>ff11000002659880: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
                                                       ^
 ff11000002659900: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
 ff11000002659980: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
==================================================================
BUG: unable to handle page fault for address: ffffffffffffffff
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 2fcf2067 
P4D 2fcf3067 PUD 2fcf5067 PMD 0 
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 1705 Comm: syz.2.15 Tainted: G    B              6.13.0-rc5 #1
Tainted: [B]=BAD_PAGE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]
RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]
RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]
RIP: 0010:compound_order include/linux/mm.h:1112 [inline]
RIP: 0010:page_size include/linux/mm.h:1311 [inline]
RIP: 0010:bh_offset include/linux/buffer_head.h:176 [inline]
RIP: 0010:submit_bh_wbc.constprop.0+0x37d/0x640 fs/buffer.c:2801
Code: 00 00 4c 89 e7 48 89 44 24 08 e8 3e 64 e9 ff 4c 89 e1 48 b8 00 00 00 00 00 fc ff df 48 c1 e9 03 80 3c 01 00 0f 85 16 02 00 00 <4d> 8b 3c 24 31 ff bd ff 0f 00 00 49 c1 ef 06 41 83 e7 01 44 89 fe
RSP: 0018:ffa0000014c1f5f0 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ff11000002659880 RCX: 1fffffffffffffff
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffffffffff
RBP: 227ffffd1bbc268c R08: 0000000000000001 R09: ffe21c00012f37ae
R10: ffe21c00012f37ad R11: ff1100000979bd6f R12: ffffffffffffffff
R13: ff11000002659890 R14: ff1100000979bd00 R15: ff11000002659880
FS:  00007f65c2298700(0000) GS:ff1100006a200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffff CR3: 00000000413da004 CR4: 0000000000771ef0
PKRU: 80000000
Call Trace:
 <TASK>
 submit_bh fs/buffer.c:2819 [inline]
 __bh_read+0xa7/0x1f0 fs/buffer.c:3088
 bh_read_nowait include/linux/buffer_head.h:442 [inline]
 __block_write_begin_int+0x156d/0x18c0 fs/buffer.c:2145
 iomap_write_begin+0x581/0x18d0 fs/iomap/buffered-io.c:827
 iomap_write_iter fs/iomap/buffered-io.c:955 [inline]
 iomap_file_buffered_write+0x402/0xbe0 fs/iomap/buffered-io.c:1039
 gfs2_file_buffered_write+0x40b/0xb10 fs/gfs2/file.c:1060
 gfs2_file_write_iter+0x6c9/0x1080 fs/gfs2/file.c:1164
 new_sync_write fs/read_write.c:586 [inline]
 vfs_write fs/read_write.c:679 [inline]
 vfs_write+0xb9b/0x10f0 fs/read_write.c:659
 ksys_write+0x122/0x240 fs/read_write.c:731
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f65c364471d
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 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f65c2297ba8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f65c3806f80 RCX: 00007f65c364471d
RDX: 0000000000001006 RSI: 0000000020001240 RDI: 0000000000000007
RBP: 00007f65c36b9425 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f65c3806f8c R14: 00007f65c3807018 R15: 00007f65c2297d40
 </TASK>
Modules linked in:
CR2: ffffffffffffffff
---[ end trace 0000000000000000 ]---
RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]
RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]
RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]
RIP: 0010:compound_order include/linux/mm.h:1112 [inline]
RIP: 0010:page_size include/linux/mm.h:1311 [inline]
RIP: 0010:bh_offset include/linux/buffer_head.h:176 [inline]
RIP: 0010:submit_bh_wbc.constprop.0+0x37d/0x640 fs/buffer.c:2801
Code: 00 00 4c 89 e7 48 89 44 24 08 e8 3e 64 e9 ff 4c 89 e1 48 b8 00 00 00 00 00 fc ff df 48 c1 e9 03 80 3c 01 00 0f 85 16 02 00 00 <4d> 8b 3c 24 31 ff bd ff 0f 00 00 49 c1 ef 06 41 83 e7 01 44 89 fe
RSP: 0018:ffa0000014c1f5f0 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ff11000002659880 RCX: 1fffffffffffffff
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffffffffff
RBP: 227ffffd1bbc268c R08: 0000000000000001 R09: ffe21c00012f37ae
R10: ffe21c00012f37ad R11: ff1100000979bd6f R12: ffffffffffffffff
R13: ff11000002659890 R14: ff1100000979bd00 R15: ff11000002659880
FS:  00007f65c2298700(0000) GS:ff1100006a200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffff CR3: 00000000413da004 CR4: 0000000000771ef0
PKRU: 80000000
----------------
Code disassembly (best guess):
   0:	00 00                	add    %al,(%rax)
   2:	4c 89 e7             	mov    %r12,%rdi
   5:	48 89 44 24 08       	mov    %rax,0x8(%rsp)
   a:	e8 3e 64 e9 ff       	callq  0xffe9644d
   f:	4c 89 e1             	mov    %r12,%rcx
  12:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  19:	fc ff df
  1c:	48 c1 e9 03          	shr    $0x3,%rcx
  20:	80 3c 01 00          	cmpb   $0x0,(%rcx,%rax,1)
  24:	0f 85 16 02 00 00    	jne    0x240
* 2a:	4d 8b 3c 24          	mov    (%r12),%r15 <-- trapping instruction
  2e:	31 ff                	xor    %edi,%edi
  30:	bd ff 0f 00 00       	mov    $0xfff,%ebp
  35:	49 c1 ef 06          	shr    $0x6,%r15
  39:	41 83 e7 01          	and    $0x1,%r15d
  3d:	44 89 fe             	mov    %r15d,%esi


---------------
thanks,
Kun Hu

Re: Bug: slab-out-of-bounds Write in __bh_read

[Jan Kara]

Hello!

On Mon 06-01-25 15:23:06, Kun Hu wrote:
> When using our customized fuzzer tool to fuzz the latest Linux kernel,
> the following crash was triggered.
> 
> HEAD commit: fc033cf25e612e840e545f8d5ad2edd6ba613ed5
> git tree: upstream
> Console output: https://drive.google.com/file/d/1-YGytaKuh9M4hI6x27YjsE0vSyRFngf5/view?usp=sharing
> Kernel config: https://drive.google.com/file/d/1n2sLNg-YcIgZqhhQqyMPTDWM_N1Pqz73/view?usp=sharing
> C reproducer: /
> Syzlang reproducer: /
> 
> We found an issue in the __bh_read function at line 3086, where a
> slab-out-of-bounds error was reported. While the BUG_ON check ensures
> that bh is locked, I suspect it’s possible that bh might have been
> released prior to the call to __bh_read. This could result in accessing
> invalid memory, ultimately triggering the reported issue.

Well, most likely the bh pointer has already been corrupted. Again, nobody
is likely to be able to debug this unless we have a reliable way to
reproduce this problem.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Bug: slab-out-of-bounds Write in __bh_read

[Kun Hu]

>> 
>> HEAD commit: fc033cf25e612e840e545f8d5ad2edd6ba613ed5
>> git tree: upstream
>> Console output: https://drive.google.com/file/d/1-YGytaKuh9M4hI6x27YjsE0vSyRFngf5/view?usp=sharing
>> Kernel config: https://drive.google.com/file/d/1n2sLNg-YcIgZqhhQqyMPTDWM_N1Pqz73/view?usp=sharing
>> C reproducer: /
>> Syzlang reproducer: /
>> 
>> We found an issue in the __bh_read function at line 3086, where a
>> slab-out-of-bounds error was reported. While the BUG_ON check ensures
>> that bh is locked, I suspect it’s possible that bh might have been
>> released prior to the call to __bh_read. This could result in accessing
>> invalid memory, ultimately triggering the reported issue.
> 
> Well, most likely the bh pointer has already been corrupted. Again, nobody
> is likely to be able to debug this unless we have a reliable way to
> reproduce this problem.


Hi, Jan.

We have obtained the reproducers of this issue for multi round testing. But, the crash location seems to vary. The crash log shows a possible deadlock occurring in “gfs2_trans_begin" in /fs/gfs2/trans.c, with duplicate registrations happening when attempting to register a "kobject."

The links of these related files are at below:

Log: https://drive.google.com/file/d/1MaRMA6WKz4e7fuDw-Yrb-Zw6GhXSIFsr/view?usp=sharing
C repro: https://drive.google.com/file/d/1VdDFjW2XNDhxe9yjb01qLblDxJpQyxzh/view?usp=sharing
Syz repro: https://drive.google.com/file/d/1sLGQnJb2-DCA6EsLia8SyOte0zKnlbF7/view?usp=sharing

———
Thanks,
Kun Hu

Re: Bug: slab-out-of-bounds Write in __bh_read

[Jan Kara]

Hello!

On Wed 08-01-25 12:08:56, Kun Hu wrote:
> >> HEAD commit: fc033cf25e612e840e545f8d5ad2edd6ba613ed5
> >> git tree: upstream
> >> Console output: https://drive.google.com/file/d/1-YGytaKuh9M4hI6x27YjsE0vSyRFngf5/view?usp=sharing
> >> Kernel config: https://drive.google.com/file/d/1n2sLNg-YcIgZqhhQqyMPTDWM_N1Pqz73/view?usp=sharing
> >> C reproducer: /
> >> Syzlang reproducer: /
> >> 
> >> We found an issue in the __bh_read function at line 3086, where a
> >> slab-out-of-bounds error was reported. While the BUG_ON check ensures
> >> that bh is locked, I suspect it’s possible that bh might have been
> >> released prior to the call to __bh_read. This could result in accessing
> >> invalid memory, ultimately triggering the reported issue.
> > 
> > Well, most likely the bh pointer has already been corrupted. Again, nobody
> > is likely to be able to debug this unless we have a reliable way to
> > reproduce this problem.
> 
> We have obtained the reproducers of this issue for multi round testing.
> But, the crash location seems to vary. The crash log shows a possible
> deadlock occurring in “gfs2_trans_begin" in /fs/gfs2/trans.c, with
> duplicate registrations happening when attempting to register a
> "kobject."

OK. Checking the syzlang reproducer the same comment as for other
filesystem bugs applies - please run with CONFIG_BLK_DEV_WRITE_MOUNTED
disabled to rule out corruption of a filesystem while it is mounted.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Bug: slab-out-of-bounds Write in __bh_read

[Kun Hu]

> 
> OK. Checking the syzlang reproducer the same comment as for other
> filesystem bugs applies - please run with CONFIG_BLK_DEV_WRITE_MOUNTED
> disabled to rule out corruption of a filesystem while it is mounted.
> 
> 

Hi Jan,

We have reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled to obtain the same crash log. The new crash log, along with C and Syzlang reproducers are provided below:

Crash log: https://drive.google.com/file/d/1FiCgo05oPheAt4sDQzRYTQwl0-CY6rvi/view?usp=sharing
C reproducer: https://drive.google.com/file/d/1TTR9cquaJcMYER6vtYUGh3gOn_mROME4/view?usp=sharing
Syzlang reproducer: https://drive.google.com/file/d/1R9QDUP2r7MI4kYMiT_yn-tzm6NqmcEW-/view?usp=sharing

I’m not sure if this is sufficient to help locate the bug? If you need additional information, please let me know.

Thanks,
Kun Hu

Re: Bug: slab-out-of-bounds Write in __bh_read

[Jan Kara]

On Fri 10-01-25 17:21:19, Kun Hu wrote:
> > 
> > OK. Checking the syzlang reproducer the same comment as for other
> > filesystem bugs applies - please run with CONFIG_BLK_DEV_WRITE_MOUNTED
> > disabled to rule out corruption of a filesystem while it is mounted.
> > 
> > 
> 
> Hi Jan,
> 
> We have reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled
> to obtain the same crash log. The new crash log, along with C and Syzlang
> reproducers are provided below:
> 
> Crash log: https://drive.google.com/file/d/1FiCgo05oPheAt4sDQzRYTQwl0-CY6rvi/view?usp=sharing
> C reproducer: https://drive.google.com/file/d/1TTR9cquaJcMYER6vtYUGh3gOn_mROME4/view?usp=sharing
> Syzlang reproducer: https://drive.google.com/file/d/1R9QDUP2r7MI4kYMiT_yn-tzm6NqmcEW-/view?usp=sharing
> 
> I’m not sure if this is sufficient to help locate the bug? If you need
> additional information, please let me know.

Thanks. Based on the crash report and the reproducer it indeed looks like
some mixing of iomap_folio_state and buffer heads attached to a folio
(iomap_folio_state is attached there but we end up calling
__block_write_begin_int() which expects buffer heads there) in GFS2. GFS2
guys, care to have a look?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Bug: slab-out-of-bounds Write in __bh_read

[Kun Hu]

> 
> Thanks. Based on the crash report and the reproducer it indeed looks like
> some mixing of iomap_folio_state and buffer heads attached to a folio
> (iomap_folio_state is attached there but we end up calling
> __block_write_begin_int() which expects buffer heads there) in GFS2. GFS2
> guys, care to have a look?
> 

Thanks to Jan.

Hi Andreas,

It seems that iomap_write_begin is expected to handle I/O directly based on folio, rather than entering the buffer head path. Is it possible that GFS2 incorrectly passes data related to buffer head to iomap_write_begin?

Could you please help us to check the exact cause of the issue?

Thanks,
Kun Hu

Re: Bug: slab-out-of-bounds Write in __bh_read

[Andreas Gruenbacher]

Hi Jan,

Am Fr., 10. Jan. 2025 um 18:18 Uhr schrieb Kun Hu <huk23@m.fudan.edu.cn>:
> > Thanks. Based on the crash report and the reproducer it indeed looks like
> > some mixing of iomap_folio_state and buffer heads attached to a folio
> > (iomap_folio_state is attached there but we end up calling
> > __block_write_begin_int() which expects buffer heads there) in GFS2. GFS2
> > guys, care to have a look?
> >
>
> Thanks to Jan.
>
> Hi Andreas,
>
> It seems that iomap_write_begin is expected to handle I/O directly based on folio, rather than entering the buffer head path. Is it possible that GFS2 incorrectly passes data related to buffer head to iomap_write_begin?
>
> Could you please help us to check the exact cause of the issue?

32generated_program.c memory maps the filesystem image, mounts it, and
then modifies it through the memory map. It's those modifications that
cause gfs2 to crash, so the test case is invalid.

Is disabling CONFIG_BLK_DEV_WRITE_MOUNTED supposed to prevent that? If
so, then it doesn't seem to be working.

Thanks,
Andreas

Re: Bug: slab-out-of-bounds Write in __bh_read

[Kun Hu]

> 
> 32generated_program.c memory maps the filesystem image, mounts it, and
> then modifies it through the memory map. It's those modifications that
> cause gfs2 to crash, so the test case is invalid.
> 
> Is disabling CONFIG_BLK_DEV_WRITE_MOUNTED supposed to prevent that? If
> so, then it doesn't seem to be working.
> 
> Thanks,
> Andreas


>  We have reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled to obtain the same crash log. The new crash log, along with C and Syzlang reproducers are provided below:

> Crash log: https://drive.google.com/file/d/1FiCgo05oPheAt4sDQzRYTQwl0-CY6rvi/view?usp=sharing
> C reproducer: https://drive.google.com/file/d/1TTR9cquaJcMYER6vtYUGh3gOn_mROME4/view?usp=sharing
> Syzlang reproducer: https://drive.google.com/file/d/1R9QDUP2r7MI4kYMiT_yn-tzm6NqmcEW-/view?usp=sharing

Hi Andreas,

As per Jan's suggestion, we’ve successfully reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled. Should you require us to test this issue again, we are happy to do so.

——
Thanks,
Kun Hu

Re: Bug: slab-out-of-bounds Write in __bh_read

[Andrew Price]

On 13/01/2025 15:54, Kun Hu wrote:
> 
>>
>> 32generated_program.c memory maps the filesystem image, mounts it, and
>> then modifies it through the memory map. It's those modifications that
>> cause gfs2 to crash, so the test case is invalid.
>>
>> Is disabling CONFIG_BLK_DEV_WRITE_MOUNTED supposed to prevent that? If
>> so, then it doesn't seem to be working.
>>
>> Thanks,
>> Andreas
> 
> 
>>   We have reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled to obtain the same crash log. The new crash log, along with C and Syzlang reproducers are provided below:
> 
>> Crash log: https://drive.google.com/file/d/1FiCgo05oPheAt4sDQzRYTQwl0-CY6rvi/view?usp=sharing
>> C reproducer: https://drive.google.com/file/d/1TTR9cquaJcMYER6vtYUGh3gOn_mROME4/view?usp=sharing
>> Syzlang reproducer: https://drive.google.com/file/d/1R9QDUP2r7MI4kYMiT_yn-tzm6NqmcEW-/view?usp=sharing
> 
> Hi Andreas,
> 
> As per Jan's suggestion, we’ve successfully reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled. Should you require us to test this issue again, we are happy to do so.
> 
FWIW the reproducer boils down to

   #include <fcntl.h>
   #include <unistd.h>
   #include <sys/ioctl.h>
   #include <linux/fs.h>

   /*
      mkfs.gfs2 -b 2048 -p lock_nolock $DEV
      mount $DEV $MNT
      cd $MNT
      /path/to/this_test
    */
   int main(void)
   {
           unsigned flag = FS_JOURNAL_DATA_FL;
           char buf[4102] = {0};
           int fd;

           /* Error checking omitted for clarity */
           fd = open("f", O_CREAT|O_RDWR);
           write(fd, buf, sizeof(buf));
           ioctl(fd, FS_IOC_SETFLAGS, &flag);
           write(fd, buf, sizeof(buf)); /* boom */
           close(fd);
           return 0;
   }

So it's switching the file to journaled data mode between two writes.

The size of the writes seems to be relevant and the fs needs to be 
created with a 2K block size (I'm guessing it could reproduce with other 
combinations).

Andy

Re: Bug: slab-out-of-bounds Write in __bh_read

[Andreas Gruenbacher]

On Mon, Jan 13, 2025 at 4:41 PM Andreas Gruenbacher <agruenba@redhat.com> wrote:
> Hi Jan,
>
> Am Fr., 10. Jan. 2025 um 18:18 Uhr schrieb Kun Hu <huk23@m.fudan.edu.cn>:
> > > Thanks. Based on the crash report and the reproducer it indeed looks like
> > > some mixing of iomap_folio_state and buffer heads attached to a folio
> > > (iomap_folio_state is attached there but we end up calling
> > > __block_write_begin_int() which expects buffer heads there) in GFS2. GFS2
> > > guys, care to have a look?
> > >
> >
> > Thanks to Jan.
> >
> > Hi Andreas,
> >
> > It seems that iomap_write_begin is expected to handle I/O directly based on folio, rather than entering the buffer head path. Is it possible that GFS2 incorrectly passes data related to buffer head to iomap_write_begin?
> >
> > Could you please help us to check the exact cause of the issue?
>
> 32generated_program.c memory maps the filesystem image, mounts it, and
> then modifies it through the memory map. It's those modifications that
> cause gfs2 to crash, so the test case is invalid.

Ah, I misread, the memory map is distinct from the filesystem. So
forget about disabling CONFIG_BLK_DEV_WRITE_MOUNTED not working.

Thanks,
Andreas

Re: Bug: slab-out-of-bounds Write in __bh_read

[Andreas Gruenbacher]

On Mon, Jan 13, 2025 at 5:12 PM Andrew Price <anprice@redhat.com> wrote:
> On 13/01/2025 15:54, Kun Hu wrote:
> >
> >>
> >> 32generated_program.c memory maps the filesystem image, mounts it, and
> >> then modifies it through the memory map. It's those modifications that
> >> cause gfs2 to crash, so the test case is invalid.
> >>
> >> Is disabling CONFIG_BLK_DEV_WRITE_MOUNTED supposed to prevent that? If
> >> so, then it doesn't seem to be working.
> >>
> >> Thanks,
> >> Andreas
> >
> >
> >>   We have reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled to obtain the same crash log. The new crash log, along with C and Syzlang reproducers are provided below:
> >
> >> Crash log: https://drive.google.com/file/d/1FiCgo05oPheAt4sDQzRYTQwl0-CY6rvi/view?usp=sharing
> >> C reproducer: https://drive.google.com/file/d/1TTR9cquaJcMYER6vtYUGh3gOn_mROME4/view?usp=sharing
> >> Syzlang reproducer: https://drive.google.com/file/d/1R9QDUP2r7MI4kYMiT_yn-tzm6NqmcEW-/view?usp=sharing
> >
> > Hi Andreas,
> >
> > As per Jan's suggestion, we’ve successfully reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled. Should you require us to test this issue again, we are happy to do so.
> >
> FWIW the reproducer boils down to
>
>    #include <fcntl.h>
>    #include <unistd.h>
>    #include <sys/ioctl.h>
>    #include <linux/fs.h>
>
>    /*
>       mkfs.gfs2 -b 2048 -p lock_nolock $DEV
>       mount $DEV $MNT
>       cd $MNT
>       /path/to/this_test
>     */
>    int main(void)
>    {
>            unsigned flag = FS_JOURNAL_DATA_FL;
>            char buf[4102] = {0};
>            int fd;
>
>            /* Error checking omitted for clarity */
>            fd = open("f", O_CREAT|O_RDWR);
>            write(fd, buf, sizeof(buf));
>            ioctl(fd, FS_IOC_SETFLAGS, &flag);
>            write(fd, buf, sizeof(buf)); /* boom */
>            close(fd);
>            return 0;
>    }
>
> So it's switching the file to journaled data mode between two writes.
>
> The size of the writes seems to be relevant and the fs needs to be
> created with a 2K block size (I'm guessing it could reproduce with other
> combinations).

I've posted a fix and pushed it to for-next:

https://lore.kernel.org/gfs2/20250114175949.1196275-1-agruenba@redhat.com/

Thanks for reporting!

Andreas

Re: Bug: slab-out-of-bounds Write in __bh_read

[Andreas Gruenbacher]

On Wed, Jan 15, 2025 at 2:25 PM Kun Hu <huk23@m.fudan.edu.cn> wrote:
> I've posted a fix and pushed it to for-next:
> https://lore.kernel.org/gfs2/20250114175949.1196275-1-agruenba@redhat.com/
>
> Thanks for your help,
> Does the patch need us to test again?

That surely wouldn't hurt, thanks.

Andreas

Re: Bug: slab-out-of-bounds Write in __bh_read

[Kun Hu]

> 2025年1月15日 02:05，Andreas Gruenbacher <agruenba@redhat.com> 写道：
> 
> On Mon, Jan 13, 2025 at 5:12 PM Andrew Price <anprice@redhat.com> wrote:
>> On 13/01/2025 15:54, Kun Hu wrote:
>>> 
>>>> 
>>>> 32generated_program.c memory maps the filesystem image, mounts it, and
>>>> then modifies it through the memory map. It's those modifications that
>>>> cause gfs2 to crash, so the test case is invalid.
>>>> 
>>>> Is disabling CONFIG_BLK_DEV_WRITE_MOUNTED supposed to prevent that? If
>>>> so, then it doesn't seem to be working.
>>>> 
>>>> Thanks,
>>>> Andreas
>>> 
>>> 
>>>>  We have reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled to obtain the same crash log. The new crash log, along with C and Syzlang reproducers are provided below:
>>> 
>>>> Crash log: https://drive.google.com/file/d/1FiCgo05oPheAt4sDQzRYTQwl0-CY6rvi/view?usp=sharing
>>>> C reproducer: https://drive.google.com/file/d/1TTR9cquaJcMYER6vtYUGh3gOn_mROME4/view?usp=sharing
>>>> Syzlang reproducer: https://drive.google.com/file/d/1R9QDUP2r7MI4kYMiT_yn-tzm6NqmcEW-/view?usp=sharing
>>> 
>>> Hi Andreas,
>>> 
>>> As per Jan's suggestion, we’ve successfully reproduced the crash with CONFIG_BLK_DEV_WRITE_MOUNTED disabled. Should you require us to test this issue again, we are happy to do so.
>>> 
>> FWIW the reproducer boils down to
>> 
>>   #include <fcntl.h>
>>   #include <unistd.h>
>>   #include <sys/ioctl.h>
>>   #include <linux/fs.h>
>> 
>>   /*
>>      mkfs.gfs2 -b 2048 -p lock_nolock $DEV
>>      mount $DEV $MNT
>>      cd $MNT
>>      /path/to/this_test
>>    */
>>   int main(void)
>>   {
>>           unsigned flag = FS_JOURNAL_DATA_FL;
>>           char buf[4102] = {0};
>>           int fd;
>> 
>>           /* Error checking omitted for clarity */
>>           fd = open("f", O_CREAT|O_RDWR);
>>           write(fd, buf, sizeof(buf));
>>           ioctl(fd, FS_IOC_SETFLAGS, &flag);
>>           write(fd, buf, sizeof(buf)); /* boom */
>>           close(fd);
>>           return 0;
>>   }
>> 
>> So it's switching the file to journaled data mode between two writes.
>> 
>> The size of the writes seems to be relevant and the fs needs to be
>> created with a 2K block size (I'm guessing it could reproduce with other
>> combinations).

Hi Andy,

Thanks for the reporting. I was unable to run the C reproducer you provided. I still reproduced the issue using syscall reproducer provided by syzkaller.

Thanks,

> 
> I've posted a fix and pushed it to for-next:
> 
> https://lore.kernel.org/gfs2/20250114175949.1196275-1-agruenba@redhat.com/
> 
> Thanks for reporting!
> 
> Andreas

> Syzlang reproducer: https://drive.google.com/file/d/1R9QDUP2r7MI4kYMiT_yn-tzm6NqmcEW-/view?usp=sharing

Hi Andreas,

Thank you for the patch. I tested it using the syscall reproducer and was still able to reproduce the issue.

Crash log: Link: https://github.com/pghk13/Kernel-Bug/blob/main/0103_6.13rc5_%E6%9C%AA%E6%8A%A5%E5%91%8A/%E5%AE%8C%E5%85%A8%E6%97%A0%E8%AE%B0%E5%BD%95/32-KASAN_%20slab-out-of-bounds%20Write%20in%20__bh_read/crashlog_0116_rc7%2Bpatch.txt

Could you confirm if the patch is intended to fully resolve this issue, or if additional changes might be required?

———
Thanks,
Kun Hu

Re: Bug: slab-out-of-bounds Write in __bh_read

[Andrew Price]

On 16/01/2025 10:41, Kun Hu wrote:
> 
>> 2025年1月15日 02:05，Andreas Gruenbacher <agruenba@redhat.com> 写道：
>> I've posted a fix and pushed it to for-next:
>>
>> https://lore.kernel.org/gfs2/20250114175949.1196275-1-agruenba@redhat.com/
>>
>> Thanks for reporting!
>>
>> Andreas
> 
>> Syzlang reproducer: https://drive.google.com/file/d/1R9QDUP2r7MI4kYMiT_yn-tzm6NqmcEW-/view?usp=sharing
> 
> Hi Andreas,
> 
> Thank you for the patch. I tested it using the syscall reproducer and was still able to reproduce the issue.
> 
> Crash log: Link: https://github.com/pghk13/Kernel-Bug/blob/main/0103_6.13rc5_%E6%9C%AA%E6%8A%A5%E5%91%8A/%E5%AE%8C%E5%85%A8%E6%97%A0%E8%AE%B0%E5%BD%95/32-KASAN_%20slab-out-of-bounds%20Write%20in%20__bh_read/crashlog_0116_rc7%2Bpatch.txt
> 

That's not the slab-out-of-bounds failure. It's failing to mount with:

"kobject: kobject_add_internal failed for syz:syz with -EEXIST, don't 
try to register things with the same name in the same directory."

This can happen when a gfs2 fs is mounted with the same locktable twice, 
so I expect it's a problem in the test. Please make sure you're running 
the same reproducer from the original report, in the same way. The patch 
fixes both reproducers for me.

Andy