Hi Kernel Maintainers,
Our tool found a kernel bug KASAN: use-after-free in ext4_find_extent. Please see the details below.
Kernel commit: v6.9 (Commits on May 12, 2024)
Kernel config: attachment
C/Syz reproducer: attachment
We find this bug was reported and marked as fixed. (https://syzkaller.appspot.com/bug?extid=7ec4ebe875a7076ebb31)
Our reproducer can trigger this bug in v6.9, so the bug may have not been fixed correctly.
Please let me know for anything I can help.
Best,
Shuangpeng
[ 104.471062][ T1049] ==================================================================
[ 104.473279][ T1049] BUG: KASAN: use-after-free in ext4_find_extent (fs/ext4/extents.c:837 fs/ext4/extents.c:953)
[ 104.475224][ T1049] Read of size 4 at addr ffff88815aec5d24 by task kworker/u10:7/1049
[ 104.477244][ T1049]
[ 104.477808][ T1049] CPU: 1 PID: 1049 Comm: kworker/u10:7 Not tainted 6.9.0 #7
[ 104.479677][ T1049] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 104.481942][ T1049] Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work
[ 104.483662][ T1049] Call Trace:
[ 104.484507][ T1049] <TASK>
[ 104.485281][ T1049] dump_stack_lvl (lib/dump_stack.c:117)
[ 104.487750][ T1049] print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
[ 104.488874][ T1049] ? __phys_addr (arch/x86/mm/physaddr.c:32 (discriminator 4))
[ 104.490057][ T1049] ? ext4_find_extent (fs/ext4/extents.c:837 fs/ext4/extents.c:953)
[ 104.491357][ T1049] kasan_report (mm/kasan/report.c:603)
[ 104.492441][ T1049] ? ext4_find_extent (fs/ext4/extents.c:837 fs/ext4/extents.c:953)
[ 104.493455][ T1049] ext4_find_extent (fs/ext4/extents.c:837 fs/ext4/extents.c:953)
[ 104.494504][ T1049] ext4_ext_map_blocks (fs/ext4/extents.c:4144)
[ 104.495628][ T1049] ? preempt_count_add (./include/linux/ftrace.h:974 kernel/sched/core.c:5852 kernel/sched/core.c:5849 kernel/sched/core.c:5877)
[ 104.496730][ T1049] ? __pfx_copy_page_from_iter_atomic (lib/iov_iter.c:462)
[ 104.498034][ T1049] ? const_folio_flags.constprop.0 (./include/linux/page-flags.h:316)
[ 104.499327][ T1049] ? noop_dirty_folio (mm/page-writeback.c:2650)
[ 104.500338][ T1049] ? folio_flags.constprop.0 (./include/linux/page-flags.h:325)
[ 104.501532][ T1049] ? inode_to_bdi (mm/backing-dev.c:1097)
[ 104.502518][ T1049] ? __pfx_ext4_ext_map_blocks (fs/ext4/extents.c:4128)
[ 104.503705][ T1049] ? shmem_write_end (mm/shmem.c:2783)
[ 104.504958][ T1049] ? generic_perform_write (mm/filemap.c:3938)
[ 104.506371][ T1049] ? __pfx_generic_perform_write (mm/filemap.c:3938)
[ 104.507787][ T1049] ? percpu_counter_add_batch (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:77 ./arch/x86/include/asm/irqflags.h:135 lib/percpu_counter.c:102)
[ 104.509268][ T1049] ? down_write (./arch/x86/include/asm/preempt.h:103 kernel/locking/rwsem.c:1309 kernel/locking/rwsem.c:1315 kernel/locking/rwsem.c:1580)
[ 104.510458][ T1049] ? __pfx_down_write (kernel/locking/rwsem.c:1577)
[ 104.511700][ T1049] ext4_map_blocks (fs/ext4/inode.c:637)
[ 104.512996][ T1049] ? __pfx_ext4_map_blocks (fs/ext4/inode.c:481)
[ 104.514325][ T1049] ? ext4_journal_check_start (fs/ext4/ext4_jbd2.c:88)
[ 104.515792][ T1049] ? __ext4_journal_start_sb (fs/ext4/ext4_jbd2.c:114)
[ 104.517222][ T1049] ? ext4_convert_unwritten_extents (fs/ext4/extents.c:4840)
[ 104.518882][ T1049] ext4_convert_unwritten_extents (fs/ext4/extents.c:4847)
[ 104.520471][ T1049] ? __pfx_ext4_convert_unwritten_extents (fs/ext4/extents.c:4818)
[ 104.522137][ T1049] ? wakeup_preempt (./arch/x86/include/asm/bitops.h:206 ./arch/x86/include/asm/bitops.h:238 ./include/asm-generic/bitops/instrumented-non-atomic.h:142 ./include/linux/thread_info.h:118 ./include/linux/sched.h:1952 ./include/linux/sched.h:1967 kernel/sched/core.c:2248)
[ 104.523257][ T1049] ext4_convert_unwritten_io_end_vec (fs/ext4/extents.c:4887)
[ 104.524747][ T1049] ? try_to_wake_up (./arch/x86/include/asm/preempt.h:103 ./include/linux/preempt.h:480 ./include/linux/preempt.h:480 kernel/sched/core.c:4233)
[ 104.525878][ T1049] ext4_end_io_rsv_work (fs/ext4/page-io.c:187 fs/ext4/page-io.c:259 fs/ext4/page-io.c:273)
[ 104.527018][ T1049] ? __pfx_ext4_end_io_rsv_work (fs/ext4/page-io.c:270)
[ 104.528352][ T1049] ? kick_pool (kernel/workqueue.c:1290)
[ 104.529398][ T1049] process_one_work (kernel/workqueue.c:3272)
[ 104.530571][ T1049] ? kthread_data (kernel/kthread.c:77 kernel/kthread.c:244)
[ 104.531647][ T1049] worker_thread (kernel/workqueue.c:3342 kernel/workqueue.c:3429)
[ 104.532769][ T1049] ? __kthread_parkme (kernel/kthread.c:293)
[ 104.533912][ T1049] ? __pfx_worker_thread (kernel/workqueue.c:3375)
[ 104.535148][ T1049] kthread (kernel/kthread.c:388)
[ 104.536104][ T1049] ? __pfx_kthread (kernel/kthread.c:341)
[ 104.537159][ T1049] ret_from_fork (arch/x86/kernel/process.c:153)
[ 104.538230][ T1049] ? __pfx_kthread (kernel/kthread.c:341)
[ 104.539234][ T1049] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
[ 104.540355][ T1049] </TASK>
[ 104.541051][ T1049]
[ 104.541606][ T1049] The buggy address belongs to the physical page:
[ 104.543248][ T1049] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x15aec5
[ 104.545380][ T1049] flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff)
[ 104.547104][ T1049] page_type: 0xffffffff()
[ 104.548186][ T1049] raw: 057ff00000000000 ffffea00056bb088 ffffea00056bb1c8 0000000000000000
[ 104.550181][ T1049] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
[ 104.552298][ T1049] page dumped because: kasan: bad access detected
[ 104.553716][ T1049] page_owner tracks the page as freed
[ 104.554946][ T1049] page last allocated via order 0, migratetype Movable, gfp_mask 0x141cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_WRITE), pid 8103, tgid 8102 (4
[ 104.559217][ T1049] post_alloc_hook (./include/linux/page_owner.h:32 mm/page_alloc.c:1534)
[ 104.560336][ T1049] get_page_from_freelist (mm/page_alloc.c:1543 mm/page_alloc.c:3317)
[ 104.561656][ T1049] __alloc_pages (mm/page_alloc.c:4576)
[ 104.562758][ T1049] alloc_pages_mpol (mm/mempolicy.c:2266)
[ 104.563885][ T1049] folio_alloc (mm/mempolicy.c:2342)
[ 104.564870][ T1049] filemap_alloc_folio (mm/filemap.c:984)
[ 104.566055][ T1049] __filemap_get_folio (mm/filemap.c:1927)
[ 104.567272][ T1049] ext4_write_begin (fs/ext4/inode.c:1161)
[ 104.568419][ T1049] ext4_da_write_begin (fs/ext4/inode.c:2869)
[ 104.569641][ T1049] generic_perform_write (mm/filemap.c:3976)
[ 104.570938][ T1049] ext4_buffered_write_iter (./include/linux/fs.h:800 fs/ext4/file.c:302)
[ 104.572260][ T1049] ext4_file_write_iter (fs/ext4/file.c:698)
[ 104.573498][ T1049] vfs_write (fs/read_write.c:498 fs/read_write.c:590)
[ 104.574510][ T1049] ksys_write (fs/read_write.c:644)
[ 104.575533][ T1049] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
[ 104.576688][ T1049] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[ 104.578060][ T1049] page last free pid 8131 tgid 8102 stack trace:
[ 104.579478][ T1049] free_unref_page_prepare (./include/linux/page_owner.h:25 mm/page_alloc.c:1141 mm/page_alloc.c:2347)
[ 104.580787][ T1049] free_unref_folios (mm/page_alloc.c:2536)
[ 104.581977][ T1049] folios_put_refs (mm/swap.c:1034)
[ 104.583141][ T1049] truncate_inode_pages_range (./include/linux/sched.h:1988 mm/truncate.c:363)
[ 104.584525][ T1049] ext4_punch_hole (fs/ext4/ext4.h:1936 fs/ext4/inode.c:3964)
[ 104.585727][ T1049] ext4_fallocate (fs/ext4/extents.c:4803)
[ 104.586820][ T1049] vfs_fallocate (fs/open.c:339)
[ 104.587933][ T1049] __x64_sys_fallocate (./include/linux/file.h:47 fs/open.c:354 fs/open.c:361 fs/open.c:359 fs/open.c:359)
[ 104.589136][ T1049] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
[ 104.590202][ T1049] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[ 104.591635][ T1049]
[ 104.592637][ T1049] Memory state around the buggy address:
[ 104.594014][ T1049] ffff88815aec5c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 104.595931][ T1049] ffff88815aec5c80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 104.597833][ T1049] >ffff88815aec5d00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 104.599718][ T1049] ^
[ 104.600903][ T1049] ffff88815aec5d80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 104.602821][ T1049] ffff88815aec5e00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 104.604620][ T1049] ==================================================================
[ 104.607028][ T8098] EXT4-fs (loop1): This should not happen!! Data will be lost
[ 104.607028][ T8098]
[ 104.610469][ T1048] EXT4-fs warning (device loop1): ext4_convert_unwritten_extents:4848: inode #15: block 1: len 1: ext4_ext_map_blocks returned -117
[ 104.613454][ T1048] EXT4-fs error (device loop1) in ext4_reserve_inode_write:5738: Corrupt filesystem
[ 104.615714][ T1048] EXT4-fs error (device loop1): ext4_convert_unwritten_extents:4853: inode #15: comm kworker/u10:6: mark_inode_dirty error
[ 104.618529][ T1048] EXT4-fs (loop1): failed to convert unwritten extents to written extents -- potential data loss! (inode 15, error -117)
[ 104.623679][ T8099] EXT4-fs (loop2): Delayed block allocation failed for inode 15 at logical offset 16 with max blocks 184 with error 117
[ 104.624339][ T8132] ------------[ cut here ]------------
[ 104.626580][ T8099] EXT4-fs (loop2): This should not happen!! Data will be lost
[ 104.626580][ T8099]
[ 104.627413][ T8132] kernel BUG at fs/ext4/extents.c:3180!
[ 104.630527][ T8132] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
[ 104.631866][ T8132] CPU: 0 PID: 8132 Comm: a.out Not tainted 6.9.0 #7
[ 104.633183][ T8132] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 104.635028][ T8132] RIP: 0010:ext4_split_extent_at (fs/ext4/extents.c:3180 (discriminator 3))
104.636331][ T8132] Code: 48 c7 c7 80 b8 80 8a 48 8b 54 24 08 0f b7 43 08 4c 8d 04 40 49 c1 e0 04 49 01 d8 e8 ba 59 ff ff e9 e3 fc ff ff e8 90 7e 58 ff <0f> 0b e8f
All code
========
0: 48 c7 c7 80 b8 80 8a mov $0xffffffff8a80b880,%rdi
7: 48 8b 54 24 08 mov 0x8(%rsp),%rdx
c: 0f b7 43 08 movzwl 0x8(%rbx),%eax
10: 4c 8d 04 40 lea (%rax,%rax,2),%r8
14: 49 c1 e0 04 shl $0x4,%r8
18: 49 01 d8 add %rbx,%r8
1b: e8 ba 59 ff ff call 0xffffffffffff59da
20: e9 e3 fc ff ff jmp 0xfffffffffffffd08
25: e8 90 7e 58 ff call 0xffffffffff587eba
2a:* 0f 0b ud2 <-- trapping instruction
2c: 8f .byte 0x8f
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: 8f .byte 0x8f
[ 104.641847][ T8132] RSP: 0018:ffffc90003f5f9b0 EFLAGS: 00010293
[ 104.643350][ T8132] RAX: 0000000000000000 RBX: 000000000000003f RCX: ffffffff822bcfe1
[ 104.645037][ T8132] RDX: ffff88801ed2c900 RSI: ffffffff822bd5c0 RDI: 0000000000000004
[ 104.646994][ T8132] RBP: ffff88801c30f630 R08: 0000000000000004 R09: 0000000000000000
[ 104.648792][ T8132] R10: 000000000000003f R11: ffff888020ebd6e8 R12: ffff88815ba75428
[ 104.650663][ T8132] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88815836b988
[ 104.652253][ T8132] FS: 00007f6bdd2cb700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
Mes[sage f 104.653844][ T8132] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 104.655856][ T8132] CR2: 000000002003d000 CR3: 0000000016fca000 CR4: 00000000000006f0
[ 104.657513][ T8132] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 104.658902][ T8132] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 104.660242][ T8132] Call Trace:
[ 104.660768][ T8132] <TASK>
[ 104.661232][ T8132] ? show_regs (arch/x86/kernel/dumpstack.c:479)
[ 104.661907][ T8132] ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)
[ 104rom .662496][ T8132] ? do_trap (arch/x86/kernel/traps.c:114 arch/x86/kernel/traps.c:155)
syslogd@syzkalle[ 104.668396][ T8132] ? ext4_split_extent_at (fs/ext4/extents.c:3180 (discriminator 3))
r at May 15 [ 104.669608][ T08132] ? 2o_error_trap+0xdc/0x150
5:38 ...
k[ ern104.670642][ T8132] ? ext4_split_extent_at (fs/ext4/extents.c:3180 (discriminator 3))
el:[[ 1 104.604.67182015]529[ T8132] ? ext4_split_extent_at (fs/ext4/extents.c:3180 (discriminator 3))
][ T[ 1104804.6] EXT4-f73321][ T8132] ? handle_invalid_op (arch/x86/kernel/traps.c:214)
s (l[ oop1104.67448): 5][ faiT8132] le ? ext4_split_extent_at (fs/ext4/extents.c:3180 (discriminator 3))
d to[ con 104.vert675775 un][ Tw8132] ? exc_invalid_op (arch/x86/kernel/traps.c:267)
ritt[ en 104.ext67ent690s t5][ T8132] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
o wr[ itt104en ext.678234][ entT8132] ? ext4_split_extent_at (fs/ext4/extents.c:3180 (discriminator 2))
s --[ pot 104ent.679ial d475][ T8132] ? ext4_split_extent_at (fs/ext4/extents.c:3180 (discriminator 3))
ata[ los 1s! 04.6807 (ino90][d T8132] ? ext4_split_extent_at (fs/ext4/extents.c:3180 (discriminator 3))
e 15[ 104, er.68ror 2020][-11 T81372] ? __read_extent_tree_block (fs/ext4/extents.c:590)
)
[ 104.683283][ T8132] ? __pfx_ext4_split_extent_at (fs/ext4/extents.c:3158)
[ 104.684482][ T8132] ? ext4_find_extent (fs/ext4/extents.c:967)
[ 104.685519][ T8132] ext4_ext_remove_space (fs/ext4/extents.c:2877)
[ 104.686615][ T8132] ? __pfx__raw_write_lock (kernel/locking/spinlock.c:299)
[ 104.687699][ T8132] ? __pfx__ext4_get_block (fs/ext4/inode.c:755)
[ 104.688773][ T8132] ? _raw_write_unlock (./arch/x86/include/asm/preempt.h:103 ./include/linux/rwlock_api_smp.h:226 kernel/locking/spinlock.c:342)
[ 104.689781][ T8132] ? ext4_discard_preallocations (fs/ext4/mballoc.c:5504)
[ 104.690958][ T8132] ? __pfx__raw_write_lock (kernel/locking/spinlock.c:299)
[ 104.692029][ T8132] ? ext4_da_release_space (fs/ext4/inode.c:1488)
[ 104.693114][ T8132] ? __pfx_ext4_ext_remove_space (fs/ext4/extents.c:2791)
[ 104.694249][ T8132] ? __pfx_ext4_es_remove_extent (fs/ext4/extents_status.c:1497)
[ 104.695404][ T8132] ? __pfx_down_write (kernel/locking/rwsem.c:1577)
[ 104.696407][ T8132] ? __ext4_journal_start_sb (fs/ext4/ext4_jbd2.c:110)
[ 104.697539][ T8132] ext4_punch_hole (fs/ext4/inode.c:3994)
[ 104.698502][ T8132] ? __pfx_rwsem_wake.isra.0 (kernel/locking/rwsem.c:1203)
[ 104.699566][ T8132] ext4_fallocate (fs/ext4/extents.c:4803)
[ 104.700515][ T8132] ? __pfx_ext4_fallocate (fs/ext4/extents.c:4709)
[ 104.701541][ T8132] ? avc_policy_seqno (security/selinux/avc.c:1205)
[ 104.702502][ T8132] ? selinux_file_permission (security/selinux/hooks.c:3643)
[ 104.703662][ T8132] ? __pfx_ext4_fallocate (fs/ext4/extents.c:4709)
[ 104.704710][ T8132] vfs_fallocate (fs/open.c:339)
[ 104.705647][ T8132] __x64_sys_fallocate (./include/linux/file.h:47 fs/open.c:354 fs/open.c:361 fs/open.c:359 fs/open.c:359)
[ 104.706660][ T8132] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
[ 104.707607][ T8132] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[ 104.708804][ T8132] RIP: 0033:0x7f6bdd40873d
[ 104.709686][ T8132] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 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> 3d8
All code
========
0: 00 c3 add %al,%bl
2: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
9: 00 00 00
c: 90 nop
d: f3 0f 1e fa endbr64
11: 48 89 f8 mov %rdi,%rax
14: 48 89 f7 mov %rsi,%rdi
17: 48 89 d6 mov %rdx,%rsi
1a: 48 89 ca mov %rcx,%rdx
1d: 4d 89 c2 mov %r8,%r10
20: 4d 89 c8 mov %r9,%r8
23: 4c 8b 4c 24 08 mov 0x8(%rsp),%r9
28: 0f 05 syscall
2a:* 48 rex.W <-- trapping instruction
2b: d8 .byte 0xd8
Code starting with the faulting instruction
===========================================
0: 48 rex.W
1: d8 .byte 0xd8
[ 104.713554][ T8132] RSP: 002b:00007f6bdd2cae98 EFLAGS: 00000207 ORIG_RAX: 000000000000011d
[ 104.715201][ T8132] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6bdd40873d
[ 104.716792][ T8132] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000005
[ 104.718366][ T8132] RBP: 00007f6bdd2caec0 R08: 00007f6bdd2cb700 R09: 0000000000000000
[ 104.719961][ T8132] R10: 000000000000ffff R11: 0000000000000207 R12: 00007ffec136fe7e
[ 104.721498][ T8132] R13: 00007ffec136fe7f R14: 00007ffec136ff20 R15: 00007f6bdd2cafc0
[ 104.723020][ T8132] </TASK>
[ 104.723652][ T8132] Modules linked in:
[ 104.728923][ T1049] Kernel panic - not syncing: KASAN: panic_on_warn set ...
[ 104.730764][ T1049] Kernel Offset: disabled
[ 104.731710][ T1049] Rebooting in 86400 seconds..
On Tue, May 14, 2024 at 08:40:36PM -0400, Shuangpeng Bai wrote:
> Hi Kernel Maintainers,
>
> Our tool found a kernel bug KASAN: use-after-free in ext4_find_extent. Please see the details below.
>
> Kernel commit: v6.9 (Commits on May 12, 2024)
> Kernel config: attachment
> C/Syz reproducer: attachment
>
> We find this bug was reported and marked as fixed. (https://syzkaller.appspot.com/bug?extid=7ec4ebe875a7076ebb31)
>
> Our reproducer can trigger this bug in v6.9, so the bug may have not been fixed correctly.
The reason why it was marked as fixed is because the reproducer no
longer reproduces with CONFIG_BLK_DEV_WRITE_MOUNTED disabled.
Upstream syzkaller unconditionally disables this config, and we don't
consider reproducers that have CONFIG_BLK_DEV_WRITE_MOUNTED enabled to
be a bug.
If the reproducer is actively modifying the block device (or the
underlying file for a loop device) while it is mounted, we don't
consider this a bug. This is requires root, and it's no more a
"security bug" than someone complaining that root can execute a
reboot(2) system call and calling it a "security bug".
I've looked at your "reproducer" and it does appear to be modifying
the block device while it is mounted, and the config does have
CONFIG_BLK_DEV_WRITE_MOUNTED enabled. So I don't care (tm). If you
want to put an engineer to work on addressing the bug, and the patch
is a clean and maintable code fix, I'll certainly consider the change.
But it's not something that upstream will work on a volunteer basis;
no company I am aware of is willing to pay for engineers to work on
this sort of issue.
Cheers,
- Ted
Hi Ted,
Thanks for your reply!
You are right. I disabled CONFIG_BLK_DEV_WRITE_MOUNTED and found this bug can not be triggered anymore.
I am wondering if there is any suggested way for me to check whether a bug is reproduced under a reasonable environment (such as compiling config) or not? If so, that would be very helpful.
Best,
Shuangpeng
> On May 15, 2024, at 18:49, Theodore Ts'o <[email protected]> wrote:
>
> On Tue, May 14, 2024 at 08:40:36PM -0400, Shuangpeng Bai wrote:
>> Hi Kernel Maintainers,
>>
>> Our tool found a kernel bug KASAN: use-after-free in ext4_find_extent. Please see the details below.
>>
>> Kernel commit: v6.9 (Commits on May 12, 2024)
>> Kernel config: attachment
>> C/Syz reproducer: attachment
>>
>> We find this bug was reported and marked as fixed. (https://syzkaller.appspot.com/bug?extid=7ec4ebe875a7076ebb31)
>>
>> Our reproducer can trigger this bug in v6.9, so the bug may have not been fixed correctly.
>
> The reason why it was marked as fixed is because the reproducer no
> longer reproduces with CONFIG_BLK_DEV_WRITE_MOUNTED disabled.
> Upstream syzkaller unconditionally disables this config, and we don't
> consider reproducers that have CONFIG_BLK_DEV_WRITE_MOUNTED enabled to
> be a bug.
>
> If the reproducer is actively modifying the block device (or the
> underlying file for a loop device) while it is mounted, we don't
> consider this a bug. This is requires root, and it's no more a
> "security bug" than someone complaining that root can execute a
> reboot(2) system call and calling it a "security bug".
>
> I've looked at your "reproducer" and it does appear to be modifying
> the block device while it is mounted, and the config does have
> CONFIG_BLK_DEV_WRITE_MOUNTED enabled. So I don't care (tm). If you
> want to put an engineer to work on addressing the bug, and the patch
> is a clean and maintable code fix, I'll certainly consider the change.
> But it's not something that upstream will work on a volunteer basis;
> no company I am aware of is willing to pay for engineers to work on
> this sort of issue.
>
> Cheers,
>
> - Ted
On Wed, May 15, 2024 at 08:33:33PM -0400, Shuangpeng Bai wrote:
>
> You are right. I disabled CONFIG_BLK_DEV_WRITE_MOUNTED and found
> this bug can not be triggered anymore.
>
> I am wondering if there is any suggested way for me to check whether
> a bug is reproduced under a reasonable environment (such as
> compiling config) or not? If so, that would be very helpful.
As I mentioned, the upstream syzkaller always forces the
CONFIG_BLK_DEV_WRITE_MOUNTED to be disabled. That's the best way to
check whether the bug is reproducible under a reasonable environment,
and to do it in an automated way.
Cheers,
- Ted
On Thu, 16 May 2024 at 15:58, Theodore Ts'o <[email protected]> wrote:
>
> On Wed, May 15, 2024 at 08:33:33PM -0400, Shuangpeng Bai wrote:
> >
> > You are right. I disabled CONFIG_BLK_DEV_WRITE_MOUNTED and found
> > this bug can not be triggered anymore.
> >
> > I am wondering if there is any suggested way for me to check whether
> > a bug is reproduced under a reasonable environment (such as
> > compiling config) or not? If so, that would be very helpful.
>
> As I mentioned, the upstream syzkaller always forces the
> CONFIG_BLK_DEV_WRITE_MOUNTED to be disabled. That's the best way to
> check whether the bug is reproducible under a reasonable environment,
> and to do it in an automated way.
FWIW we provide configs used by syzbot here (upstream-*):
https://github.com/google/syzkaller/tree/master/dashboard/config/linux
+ a bunch of configs fragments with explanations why things are
enabled/disabled:
https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/maintained.yml
https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/base.yml
https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/debug.yml
I will follow the suggestions. Thank you!
> On May 16, 2024, at 10:44, Dmitry Vyukov <[email protected]> wrote:
>
> On Thu, 16 May 2024 at 15:58, Theodore Ts'o <[email protected]> wrote:
>>
>> On Wed, May 15, 2024 at 08:33:33PM -0400, Shuangpeng Bai wrote:
>>>
>>> You are right. I disabled CONFIG_BLK_DEV_WRITE_MOUNTED and found
>>> this bug can not be triggered anymore.
>>>
>>> I am wondering if there is any suggested way for me to check whether
>>> a bug is reproduced under a reasonable environment (such as
>>> compiling config) or not? If so, that would be very helpful.
>>
>> As I mentioned, the upstream syzkaller always forces the
>> CONFIG_BLK_DEV_WRITE_MOUNTED to be disabled. That's the best way to
>> check whether the bug is reproducible under a reasonable environment,
>> and to do it in an automated way.
>
> FWIW we provide configs used by syzbot here (upstream-*):
> https://github.com/google/syzkaller/tree/master/dashboard/config/linux
>
> + a bunch of configs fragments with explanations why things are
> enabled/disabled:
> https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/maintained.yml
> https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/base.yml
> https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/debug.yml