* [Bug 215941] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image @ 2022-05-04 19:42 bugzilla-daemon 2022-08-05 14:00 ` [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero Luís Henriques ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: bugzilla-daemon @ 2022-05-04 19:42 UTC (permalink / raw) To: linux-ext4 https://bugzilla.kernel.org/show_bug.cgi?id=215941 Bug ID: 215941 Summary: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image Product: File System Version: 2.5 Kernel Version: 5.18, 5.17 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext4 Assignee: fs_ext4@kernel-bugs.osdl.org Reporter: wenqingliu0120@gmail.com Regression: No Created attachment 300878 --> https://bugzilla.kernel.org/attachment.cgi?id=300878&action=edit poc and .config - Overview FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() and causing general protection fault when mount and operate on crafted image - Reproduce tested on kernel 5.18-rc5, 5.17.X # mkdir test_crash # cd test_crash # unzip tmp118.zip # mkdir mnt # ./single_test.sh ext4 118 -Kernel dump [ 39.470657] loop5: detected capacity change from 0 to 32768 [ 39.500549] EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support! [ 39.547582] EXT4-fs (loop5): mounted filesystem with journalled data mode. Quota mode: none. [ 39.547804] ext4 filesystem being mounted at /home/wq/test_crashes/mnt supports timestamps until 2038 (0x7fffffff) [ 39.695260] EXT4-fs error (device loop5): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 7551 vs 7520 free clusters [ 39.700838] ------------[ cut here ]------------ [ 39.700841] kernel BUG at fs/ext4/extents.c:2258! [ 39.700894] invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 39.700922] CPU: 3 PID: 1021 Comm: tmp118 Not tainted 5.18.0-rc5 #1 [ 39.700949] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 39.700984] RIP: 0010:ext4_ext_map_blocks+0x189b/0x3710 [ 39.701009] Code: ef 44 39 fb 0f 82 9f 1d 00 00 48 89 f7 44 89 fb e8 0a 1e ff ff 41 89 c6 41 89 c5 8d 48 ff 45 29 fe 41 39 c7 0f 85 ef f7 ff ff <0f> 0b b9 fe ff ff ff 41 bd ff ff ff ff 31 db 41 be ff ff ff ff e9 [ 39.701080] RSP: 0018:ffffc900006d73a8 EFLAGS: 00010246 [ 39.701103] RAX: 0000000000000024 RBX: 0000000000000024 RCX: 0000000000000023 [ 39.701132] RDX: 0000000000000000 RSI: ffff8881250f3000 RDI: ffff88810b911968 [ 39.701160] RBP: ffff88810b911a78 R08: 0000000000000024 R09: 0000000000002602 [ 39.701189] R10: ffff88810b911956 R11: ffff88812cc3b810 R12: ffffc900006d7760 [ 39.701217] R13: 0000000000000024 R14: 0000000000000000 R15: 0000000000000024 [ 39.701246] FS: 00007faab09cd540(0000) GS:ffff888293780000(0000) knlGS:0000000000000000 [ 39.701278] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 39.701301] CR2: 000055cb4ab92008 CR3: 000000011f47c004 CR4: 0000000000370ee0 [ 39.701332] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 39.701360] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 39.701389] Call Trace: [ 39.701401] <TASK> [ 39.701412] ? __kasan_record_aux_stack+0xb1/0xc0 [ 39.701435] ? ext4_ext_release+0x10/0x10 [ 39.701453] ? __radix_tree_lookup+0x9b/0x280 [ 39.701474] ? __queue_work+0x3bc/0xd80 [ 39.701493] ? radix_tree_insert+0x550/0x550 [ 39.701513] ? kmem_cache_alloc+0x134/0x4c0 [ 39.701532] ? down_read+0x126/0x210 [ 39.701550] ? down_write+0x120/0x120 [ 39.701567] ? _raw_read_unlock+0x26/0x40 [ 39.701586] ? ext4_es_lookup_extent+0x3aa/0x960 [ 39.701606] ext4_map_blocks+0x726/0x13f0 [ 39.701626] ? ext4_issue_zeroout+0x180/0x180 [ 39.701646] ? xa_load+0xbc/0x110 [ 39.701661] ? xas_free_nodes+0x280/0x280 [ 39.701679] ? bio_add_page+0x10d/0x170 [ 39.701698] ? kasan_unpoison+0x3e/0x70 [ 39.701716] ext4_mpage_readpages+0xa62/0x19c0 [ 39.701738] ? verity_work+0x90/0x90 [ 39.701758] ? __mod_lruvec_page_state+0x1a9/0x3c0 [ 39.701780] ? __filemap_add_folio+0x512/0xc20 [ 39.701805] read_pages+0x191/0xa60 [ 39.701822] ? __alloc_pages+0x2d6/0x5c0 [ 39.701841] ? pagevec_add_and_need_flush+0xd6/0x110 [ 39.702576] ? file_ra_state_init+0xd0/0xd0 [ 39.703289] ? folio_add_lru+0xa0/0x100 [ 39.703999] ? policy_node+0xb9/0x140 [ 39.704688] page_cache_ra_unbounded+0x25b/0x410 [ 39.705391] filemap_get_pages+0x4f1/0x1270 [ 39.706047] ? filemap_fault+0x1b40/0x1b40 [ 39.706698] ? __stack_depot_save+0x34/0x530 [ 39.707342] ? kasan_save_stack+0x2e/0x40 [ 39.707969] filemap_read+0x28c/0x930 [ 39.708578] ? entry_SYSCALL_64_after_hwframe+0x44/0xae [ 39.709237] ? filemap_get_pages+0x1270/0x1270 [ 39.709814] ? may_open_dev+0xd0/0xd0 [ 39.710374] new_sync_read+0x2f6/0x540 [ 39.710925] ? __x64_sys_llseek+0x2e0/0x2e0 [ 39.711474] ? __inode_security_revalidate+0xb2/0xd0 [ 39.712021] ? security_file_permission+0x309/0x580 [ 39.712566] vfs_read+0x337/0x460 [ 39.713153] ksys_read+0xed/0x1c0 [ 39.713675] ? vfs_write+0x7b0/0x7b0 [ 39.714186] ? exit_to_user_mode_prepare+0x149/0x160 [ 39.714698] do_syscall_64+0x38/0x90 [ 39.715203] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 39.715722] RIP: 0033:0x7faab08f276d [ 39.716230] 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> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f3 36 0d 00 f7 d8 64 89 01 48 [ 39.717403] RSP: 002b:00007ffd87bc35d8 EFLAGS: 00000203 ORIG_RAX: 0000000000000000 [ 39.717986] RAX: ffffffffffffffda RBX: 000055cb4ab91940 RCX: 00007faab08f276d [ 39.718577] RDX: 000000000000144b RSI: 00007ffd87bc4840 RDI: 0000000000000003 [ 39.719174] RBP: 00007ffd87bc8850 R08: 00007ffd87bc8948 R09: 00007ffd87bc8948 [ 39.719774] R10: 00007faab09e8d50 R11: 0000000000000203 R12: 000055cb4ab910a0 [ 39.720377] R13: 00007ffd87bc8940 R14: 0000000000000000 R15: 0000000000000000 [ 39.720986] </TASK> [ 39.721589] Modules linked in: joydev input_leds serio_raw qemu_fw_cfg xfs autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear hid_generic qxl usbhid hid drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect crct10dif_pclmul sysimgblt fb_sys_fops crc32_pclmul drm ghash_clmulni_intel aesni_intel psmouse crypto_simd cryptd [ 39.724453] ---[ end trace 0000000000000000 ]--- [ 39.725271] RIP: 0010:ext4_ext_map_blocks+0x189b/0x3710 [ 39.726014] Code: ef 44 39 fb 0f 82 9f 1d 00 00 48 89 f7 44 89 fb e8 0a 1e ff ff 41 89 c6 41 89 c5 8d 48 ff 45 29 fe 41 39 c7 0f 85 ef f7 ff ff <0f> 0b b9 fe ff ff ff 41 bd ff ff ff ff 31 db 41 be ff ff ff ff e9 [ 39.727593] RSP: 0018:ffffc900006d73a8 EFLAGS: 00010246 [ 39.728424] RAX: 0000000000000024 RBX: 0000000000000024 RCX: 0000000000000023 [ 39.729282] RDX: 0000000000000000 RSI: ffff8881250f3000 RDI: ffff88810b911968 [ 39.730101] RBP: ffff88810b911a78 R08: 0000000000000024 R09: 0000000000002602 [ 39.730937] R10: ffff88810b911956 R11: ffff88812cc3b810 R12: ffffc900006d7760 [ 39.731766] R13: 0000000000000024 R14: 0000000000000000 R15: 0000000000000024 [ 39.732600] FS: 00007faab09cd540(0000) GS:ffff888293780000(0000) knlGS:0000000000000000 [ 39.733508] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 39.734357] CR2: 000055cb4ab92008 CR3: 000000011f47c004 CR4: 0000000000370ee0 [ 39.735234] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 39.736104] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 39.737015] ------------[ cut here ]------------ [ 39.737865] WARNING: CPU: 3 PID: 1021 at kernel/exit.c:741 do_exit+0x17cb/0x2770 [ 39.738751] Modules linked in: joydev input_leds serio_raw qemu_fw_cfg xfs autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear hid_generic qxl usbhid hid drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect crct10dif_pclmul sysimgblt fb_sys_fops crc32_pclmul drm ghash_clmulni_intel aesni_intel psmouse crypto_simd cryptd [ 39.742529] CPU: 3 PID: 1021 Comm: tmp118 Tainted: G D 5.18.0-rc5 #1 [ 39.743523] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 39.744526] RIP: 0010:do_exit+0x17cb/0x2770 [ 39.745532] Code: 01 05 99 8c 2a 52 e9 92 fc ff ff 48 89 df e8 5c c5 27 00 e9 ec ee ff ff 4c 89 e6 bf 05 06 00 00 e8 6a 4a 02 00 e9 98 eb ff ff <0f> 0b e9 c7 e8 ff ff 48 8b 54 24 08 b8 ff ff 37 00 48 c1 e0 2a 48 [ 39.747649] RSP: 0018:ffffc900006d7e48 EFLAGS: 00010282 [ 39.748716] RAX: 1ffff1102535e195 RBX: ffff888129af0000 RCX: 0000000000000000 [ 39.749787] RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff888129af0ca8 [ 39.750882] RBP: ffff888129af0000 R08: 0000000000000041 R09: fffff520000da000 [ 39.751966] R10: ffff8882937a84cb R11: ffffed10526f5099 R12: 000000000000000b [ 39.753056] R13: ffffffffb06221c0 R14: ffff888129af0000 R15: 0000000000000000 [ 39.754140] FS: 00007faab09cd540(0000) GS:ffff888293780000(0000) knlGS:0000000000000000 [ 39.755247] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 39.756341] CR2: 000055cb4ab92008 CR3: 000000011f47c004 CR4: 0000000000370ee0 [ 39.757434] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 39.758500] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 39.759559] Call Trace: [ 39.760590] <TASK> [ 39.761614] ? vfs_read+0x337/0x460 [ 39.762651] ? mm_update_next_owner+0x6d0/0x6d0 [ 39.763676] ? vfs_write+0x7b0/0x7b0 [ 39.764700] make_task_dead+0xb0/0xc0 [ 39.765709] rewind_stack_and_make_dead+0x17/0x17 [ 39.766719] RIP: 0033:0x7faab08f276d [ 39.767661] 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> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f3 36 0d 00 f7 d8 64 89 01 48 [ 39.769610] RSP: 002b:00007ffd87bc35d8 EFLAGS: 00000203 ORIG_RAX: 0000000000000000 [ 39.770565] RAX: ffffffffffffffda RBX: 000055cb4ab91940 RCX: 00007faab08f276d [ 39.771537] RDX: 000000000000144b RSI: 00007ffd87bc4840 RDI: 0000000000000003 [ 39.772485] RBP: 00007ffd87bc8850 R08: 00007ffd87bc8948 R09: 00007ffd87bc8948 [ 39.773455] R10: 00007faab09e8d50 R11: 0000000000000203 R12: 000055cb4ab910a0 [ 39.774406] R13: 00007ffd87bc8940 R14: 0000000000000000 R15: 0000000000000000 [ 39.775330] </TASK> [ 39.776226] ---[ end trace 0000000000000000 ]--- [ 39.777391] general protection fault, probably for non-canonical address 0xe3fffb240001b5e6: 0000 [#2] PREEMPT SMP KASAN NOPTI [ 39.779488] KASAN: maybe wild-memory-access in range [0x1ffff920000daf30-0x1ffff920000daf37] [ 39.780507] CPU: 2 PID: 1021 Comm: tmp118 Tainted: G D W 5.18.0-rc5 #1 [ 39.781584] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 39.782653] RIP: 0010:__blk_flush_plug+0x144/0x610 [ 39.783701] Code: 00 4c 8b 74 24 68 0f 85 72 03 00 00 41 80 3c 1a 00 4c 8b 7d 18 0f 85 8c 03 00 00 49 8d 7f 08 4c 8b 65 20 48 89 fe 48 c1 ee 03 <80> 3c 1e 00 0f 85 c9 03 00 00 4c 89 e6 49 89 4f 08 48 c1 ee 03 4c [ 39.787041] RSP: 0018:ffffc900006d7a58 EFLAGS: 00010202 [ 39.788145] RAX: ffffc900006d78f8 RBX: dffffc0000000000 RCX: ffffc900006d7ac0 [ 39.789303] RDX: fffff520000daf1f RSI: 03ffff240001b5e6 RDI: 1ffff920000daf32 [ 39.790359] RBP: ffffc900006d78e0 R08: 0000000000000001 R09: ffffed102172234b [ 39.791434] R10: 1ffff920000daf20 R11: ffffed102172234a R12: ffffc900006d7aa8 [ 39.792464] R13: fffff520000daf1f R14: ffffc900006d7ac0 R15: 1ffff920000daf2a [ 39.793483] FS: 0000000000000000(0000) GS:ffff888293700000(0000) knlGS:0000000000000000 [ 39.794442] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 39.795436] CR2: 00007f66080200d8 CR3: 000000022e20e002 CR4: 0000000000370ee0 [ 39.796353] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 39.797290] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 39.798158] Call Trace: [ 39.799013] <TASK> [ 39.799854] ? _raw_spin_lock_irqsave+0x98/0xf0 [ 39.800773] ? blk_start_plug_nr_ios+0x270/0x270 [ 39.801637] ? _raw_spin_lock_irq+0x8d/0xe0 [ 39.802482] schedule+0x193/0x1f0 [ 39.803313] rwsem_down_write_slowpath+0x5cf/0xee0 [ 39.804142] ? rwsem_down_read_slowpath+0x880/0x880 [ 39.805053] ? lru_lazyfree_fn+0x1400/0x1400 [ 39.805874] ? free_unref_page_commit+0x354/0x800 [ 39.806701] ? remove_vma+0xf8/0x130 [ 39.807516] ? kmem_cache_free+0xc6/0x530 [ 39.808335] down_write+0x104/0x120 [ 39.809236] ? down_write_killable+0x130/0x130 [ 39.810059] ? fcntl_setlk+0x930/0x930 [ 39.810880] ext4_release_file+0x254/0x2e0 [ 39.811703] __fput+0x1e9/0x8b0 [ 39.812522] task_work_run+0xca/0x150 [ 39.813382] do_exit+0x8b6/0x2770 [ 39.814176] ? mm_update_next_owner+0x6d0/0x6d0 [ 39.814953] ? vfs_write+0x7b0/0x7b0 [ 39.815713] make_task_dead+0xb0/0xc0 [ 39.816474] rewind_stack_and_make_dead+0x17/0x17 [ 39.817492] RIP: 0033:0x7faab08f276d [ 39.818240] Code: Unable to access opcode bytes at RIP 0x7faab08f2743. [ 39.819005] RSP: 002b:00007ffd87bc35d8 EFLAGS: 00000203 ORIG_RAX: 0000000000000000 [ 39.819780] RAX: ffffffffffffffda RBX: 000055cb4ab91940 RCX: 00007faab08f276d [ 39.820551] RDX: 000000000000144b RSI: 00007ffd87bc4840 RDI: 0000000000000003 [ 39.821372] RBP: 00007ffd87bc8850 R08: 00007ffd87bc8948 R09: 00007ffd87bc8948 [ 39.822126] R10: 00007faab09e8d50 R11: 0000000000000203 R12: 000055cb4ab910a0 [ 39.822858] R13: 00007ffd87bc8940 R14: 0000000000000000 R15: 0000000000000000 [ 39.823575] </TASK> [ 39.824270] Modules linked in: joydev input_leds serio_raw qemu_fw_cfg xfs autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear hid_generic qxl usbhid hid drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect crct10dif_pclmul sysimgblt fb_sys_fops crc32_pclmul drm ghash_clmulni_intel aesni_intel psmouse crypto_simd cryptd [ 39.827352] ---[ end trace 0000000000000000 ]--- [ 39.828094] RIP: 0010:ext4_ext_map_blocks+0x189b/0x3710 [ 39.828865] Code: ef 44 39 fb 0f 82 9f 1d 00 00 48 89 f7 44 89 fb e8 0a 1e ff ff 41 89 c6 41 89 c5 8d 48 ff 45 29 fe 41 39 c7 0f 85 ef f7 ff ff <0f> 0b b9 fe ff ff ff 41 bd ff ff ff ff 31 db 41 be ff ff ff ff e9 [ 39.830387] RSP: 0018:ffffc900006d73a8 EFLAGS: 00010246 [ 39.831172] RAX: 0000000000000024 RBX: 0000000000000024 RCX: 0000000000000023 [ 39.831952] RDX: 0000000000000000 RSI: ffff8881250f3000 RDI: ffff88810b911968 [ 39.832766] RBP: ffff88810b911a78 R08: 0000000000000024 R09: 0000000000002602 [ 39.833535] R10: ffff88810b911956 R11: ffff88812cc3b810 R12: ffffc900006d7760 [ 39.834302] R13: 0000000000000024 R14: 0000000000000000 R15: 0000000000000024 [ 39.835080] FS: 0000000000000000(0000) GS:ffff888293700000(0000) knlGS:0000000000000000 [ 39.835879] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 39.836789] CR2: 00007f66080200d8 CR3: 000000022e20e002 CR4: 0000000000370ee0 [ 39.837671] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 39.838588] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 39.839445] Fixing recursive fault but reboot is needed! [ 39.840420] BUG: using smp_processor_id() in preemptible [00000000] code: tmp118/1021 [ 39.841391] caller is __schedule+0x82/0x2300 [ 39.842273] CPU: 2 PID: 1021 Comm: tmp118 Tainted: G D W 5.18.0-rc5 #1 [ 39.843221] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 39.844195] Call Trace: [ 39.845151] <TASK> [ 39.846012] dump_stack_lvl+0x45/0x5a [ 39.846959] check_preemption_disabled+0xdd/0xe0 [ 39.847858] __schedule+0x82/0x2300 [ 39.848824] ? _printk+0xb2/0xe3 [ 39.849718] ? __sched_text_start+0x8/0x8 [ 39.850666] ? _raw_spin_lock_irq+0xe0/0xe0 [ 39.851568] do_task_dead+0xa0/0xc0 [ 39.852439] make_task_dead.cold+0x9c/0x160 [ 39.853406] rewind_stack_and_make_dead+0x17/0x17 [ 39.854320] RIP: 0033:0x7faab08f276d [ 39.855224] Code: Unable to access opcode bytes at RIP 0x7faab08f2743. [ 39.856112] RSP: 002b:00007ffd87bc35d8 EFLAGS: 00000203 ORIG_RAX: 0000000000000000 [ 39.857067] RAX: ffffffffffffffda RBX: 000055cb4ab91940 RCX: 00007faab08f276d [ 39.857941] RDX: 000000000000144b RSI: 00007ffd87bc4840 RDI: 0000000000000003 [ 39.858809] RBP: 00007ffd87bc8850 R08: 00007ffd87bc8948 R09: 00007ffd87bc8948 [ 39.859668] R10: 00007faab09e8d50 R11: 0000000000000203 R12: 000055cb4ab910a0 [ 39.860530] R13: 00007ffd87bc8940 R14: 0000000000000000 R15: 0000000000000000 [ 39.861430] </TASK> [ 39.862293] BUG: scheduling while atomic: tmp118/1021/0x00000000 [ 39.863165] Modules linked in: joydev input_leds serio_raw qemu_fw_cfg xfs autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear hid_generic qxl usbhid hid drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect crct10dif_pclmul sysimgblt fb_sys_fops crc32_pclmul drm ghash_clmulni_intel aesni_intel psmouse crypto_simd cryptd [ 39.866853] Preemption disabled at: [ 39.866854] [<0000000000000000>] 0x0 [ 39.868562] CPU: 2 PID: 1021 Comm: tmp118 Tainted: G D W 5.18.0-rc5 #1 [ 39.869460] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 39.870328] Call Trace: [ 39.871169] <TASK> [ 39.871982] dump_stack_lvl+0x45/0x5a [ 39.872837] __schedule_bug.cold+0x122/0x132 [ 39.873636] __schedule+0x1715/0x2300 [ 39.874427] ? __sched_text_start+0x8/0x8 [ 39.875210] ? _raw_spin_lock_irq+0xe0/0xe0 [ 39.875990] do_task_dead+0xa0/0xc0 [ 39.876806] make_task_dead.cold+0x9c/0x160 [ 39.877571] rewind_stack_and_make_dead+0x17/0x17 [ 39.878331] RIP: 0033:0x7faab08f276d [ 39.879079] Code: Unable to access opcode bytes at RIP 0x7faab08f2743. [ 39.879843] RSP: 002b:00007ffd87bc35d8 EFLAGS: 00000203 ORIG_RAX: 0000000000000000 [ 39.880628] RAX: ffffffffffffffda RBX: 000055cb4ab91940 RCX: 00007faab08f276d [ 39.881455] RDX: 000000000000144b RSI: 00007ffd87bc4840 RDI: 0000000000000003 [ 39.882231] RBP: 00007ffd87bc8850 R08: 00007ffd87bc8948 R09: 00007ffd87bc8948 [ 39.882996] R10: 00007faab09e8d50 R11: 0000000000000203 R12: 000055cb4ab910a0 [ 39.883757] R13: 00007ffd87bc8940 R14: 0000000000000000 R15: 0000000000000000 [ 39.884504] </TASK> -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero 2022-05-04 19:42 [Bug 215941] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon @ 2022-08-05 14:00 ` Luís Henriques 2022-08-11 17:24 ` Luís Henriques 2022-08-12 2:33 ` Baokun Li 2022-10-04 9:14 ` [Bug 215941] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon 2022-10-04 19:48 ` bugzilla-daemon 2 siblings, 2 replies; 7+ messages in thread From: Luís Henriques @ 2022-08-05 14:00 UTC (permalink / raw) To: Theodore Ts'o, Andreas Dilger Cc: wenqingliu0120, linux-ext4, linux-kernel, Luís Henriques When walking through an inode extents, the ext4_ext_binsearch_idx() function assumes that the extent header has been previously validated. However, there are no checks that verify that the number of entries (eh->eh_entries) is non-zero. And this will lead to problems because the EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this: [ 135.245946] ------------[ cut here ]------------ [ 135.247579] kernel BUG at fs/ext4/extents.c:2258! [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4 [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 [ 135.256475] Code: [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246 [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024 [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0 [ 135.277952] Call Trace: [ 135.278635] <TASK> [ 135.279247] ? preempt_count_add+0x6d/0xa0 [ 135.280358] ? percpu_counter_add_batch+0x55/0xb0 [ 135.281612] ? _raw_read_unlock+0x18/0x30 [ 135.282704] ext4_map_blocks+0x294/0x5a0 [ 135.283745] ? xa_load+0x6f/0xa0 [ 135.284562] ext4_mpage_readpages+0x3d6/0x770 [ 135.285646] read_pages+0x67/0x1d0 [ 135.286492] ? folio_add_lru+0x51/0x80 [ 135.287441] page_cache_ra_unbounded+0x124/0x170 [ 135.288510] filemap_get_pages+0x23d/0x5a0 [ 135.289457] ? path_openat+0xa72/0xdd0 [ 135.290332] filemap_read+0xbf/0x300 [ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40 [ 135.292192] new_sync_read+0x103/0x170 [ 135.293014] vfs_read+0x15d/0x180 [ 135.293745] ksys_read+0xa1/0xe0 [ 135.294461] do_syscall_64+0x3c/0x80 [ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Unfortunately, __ext4_ext_check() only verifies that eh->eh_entries doesn't exceed eh->eh_max. And since an empty leaf seems to be a valid value in same cases, adding this extra check there isn't an option. This patch simply adds the check directly in ext4_ext_binsearch_idx() and propagates this error so that the kernel doesn't hit this BUG_ON() in ext4_ext_determine_hole(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=215941 Signed-off-by: Luís Henriques <lhenriques@suse.de> --- fs/ext4/extents.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) Hi! This bug is easily reproducible using the filesystem image provided -- it's just a matter of mounting it and run: $ cat /mnt/foo/bar/xattr Anyway, I hope my analysis of the bug is correct -- the root cause seems to be an extent header with an invalid value for in eh_entries, which will later cause the BUG_ON(). Cheers, -- Luís diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index c148bb97b527..53cfe2c681c4 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -738,7 +738,7 @@ void ext4_ext_drop_refs(struct ext4_ext_path *path) * binary search for the closest index of the given block * the header must be checked before calling this */ -static void +static int ext4_ext_binsearch_idx(struct inode *inode, struct ext4_ext_path *path, ext4_lblk_t block) { @@ -748,6 +748,11 @@ ext4_ext_binsearch_idx(struct inode *inode, ext_debug(inode, "binsearch for %u(idx): ", block); + if (eh->eh_entries == 0) { + EXT4_ERROR_INODE(inode, "No entries in extent header!"); + return -EFSCORRUPTED; + } + l = EXT_FIRST_INDEX(eh) + 1; r = EXT_LAST_INDEX(eh); while (l <= r) { @@ -791,7 +796,7 @@ ext4_ext_binsearch_idx(struct inode *inode, BUG_ON(chix != path->p_idx); } #endif - + return 0; } /* @@ -919,7 +924,9 @@ ext4_find_extent(struct inode *inode, ext4_lblk_t block, ext_debug(inode, "depth %d: num %d, max %d\n", ppos, le16_to_cpu(eh->eh_entries), le16_to_cpu(eh->eh_max)); - ext4_ext_binsearch_idx(inode, path + ppos, block); + ret = ext4_ext_binsearch_idx(inode, path + ppos, block); + if (ret < 0) + goto err; path[ppos].p_block = ext4_idx_pblock(path[ppos].p_idx); path[ppos].p_depth = i; path[ppos].p_ext = NULL; ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero 2022-08-05 14:00 ` [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero Luís Henriques @ 2022-08-11 17:24 ` Luís Henriques 2022-08-12 2:33 ` Baokun Li 1 sibling, 0 replies; 7+ messages in thread From: Luís Henriques @ 2022-08-11 17:24 UTC (permalink / raw) To: Theodore Ts'o, Andreas Dilger Cc: wenqingliu0120, linux-ext4, linux-kernel On Fri, Aug 05, 2022 at 03:00:25PM +0100, Luís Henriques wrote: > When walking through an inode extents, the ext4_ext_binsearch_idx() function > assumes that the extent header has been previously validated. However, > there are no checks that verify that the number of entries (eh->eh_entries) > is non-zero. And this will lead to problems because the EXT_FIRST_INDEX() > and EXT_LAST_INDEX() will return garbage and result in this: > > [ 135.245946] ------------[ cut here ]------------ > [ 135.247579] kernel BUG at fs/ext4/extents.c:2258! > [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP > [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4 > [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 > [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 > [ 135.256475] Code: > [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246 > [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 > [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c > [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c > [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024 > [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 > [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 > [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0 > [ 135.277952] Call Trace: > [ 135.278635] <TASK> > [ 135.279247] ? preempt_count_add+0x6d/0xa0 > [ 135.280358] ? percpu_counter_add_batch+0x55/0xb0 > [ 135.281612] ? _raw_read_unlock+0x18/0x30 > [ 135.282704] ext4_map_blocks+0x294/0x5a0 > [ 135.283745] ? xa_load+0x6f/0xa0 > [ 135.284562] ext4_mpage_readpages+0x3d6/0x770 > [ 135.285646] read_pages+0x67/0x1d0 > [ 135.286492] ? folio_add_lru+0x51/0x80 > [ 135.287441] page_cache_ra_unbounded+0x124/0x170 > [ 135.288510] filemap_get_pages+0x23d/0x5a0 > [ 135.289457] ? path_openat+0xa72/0xdd0 > [ 135.290332] filemap_read+0xbf/0x300 > [ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40 > [ 135.292192] new_sync_read+0x103/0x170 > [ 135.293014] vfs_read+0x15d/0x180 > [ 135.293745] ksys_read+0xa1/0xe0 > [ 135.294461] do_syscall_64+0x3c/0x80 > [ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0 > > Unfortunately, __ext4_ext_check() only verifies that eh->eh_entries doesn't > exceed eh->eh_max. And since an empty leaf seems to be a valid value in > same cases, adding this extra check there isn't an option. > > This patch simply adds the check directly in ext4_ext_binsearch_idx() and > propagates this error so that the kernel doesn't hit this BUG_ON() in > ext4_ext_determine_hole(). > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=215941 > Signed-off-by: Luís Henriques <lhenriques@suse.de> > --- > fs/ext4/extents.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > Hi! > > This bug is easily reproducible using the filesystem image provided -- > it's just a matter of mounting it and run: > > $ cat /mnt/foo/bar/xattr > > Anyway, I hope my analysis of the bug is correct -- the root cause seems > to be an extent header with an invalid value for in eh_entries, which will > later cause the BUG_ON(). Although I did got any feedback yet, it looks like this patch also fixes bugzilla #216283. This issue is quite similar, but the BUG_ON() (a different one) is hit on the write path. Doing something like: $ echo 123 > /mnt/foo/bar/acl ; sync is enough to crash the kernel with that image. Also, in the bug my patch initially refers to, the eh_entries field is '0' right on the root inode (i.e., in the extent header in the inode.i_block). For this other bug, this happens in a non-root node. Cheers, -- Luís > > Cheers, > -- > Luís > > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > index c148bb97b527..53cfe2c681c4 100644 > --- a/fs/ext4/extents.c > +++ b/fs/ext4/extents.c > @@ -738,7 +738,7 @@ void ext4_ext_drop_refs(struct ext4_ext_path *path) > * binary search for the closest index of the given block > * the header must be checked before calling this > */ > -static void > +static int > ext4_ext_binsearch_idx(struct inode *inode, > struct ext4_ext_path *path, ext4_lblk_t block) > { > @@ -748,6 +748,11 @@ ext4_ext_binsearch_idx(struct inode *inode, > > ext_debug(inode, "binsearch for %u(idx): ", block); > > + if (eh->eh_entries == 0) { > + EXT4_ERROR_INODE(inode, "No entries in extent header!"); > + return -EFSCORRUPTED; > + } > + > l = EXT_FIRST_INDEX(eh) + 1; > r = EXT_LAST_INDEX(eh); > while (l <= r) { > @@ -791,7 +796,7 @@ ext4_ext_binsearch_idx(struct inode *inode, > BUG_ON(chix != path->p_idx); > } > #endif > - > + return 0; > } > > /* > @@ -919,7 +924,9 @@ ext4_find_extent(struct inode *inode, ext4_lblk_t block, > ext_debug(inode, "depth %d: num %d, max %d\n", > ppos, le16_to_cpu(eh->eh_entries), le16_to_cpu(eh->eh_max)); > > - ext4_ext_binsearch_idx(inode, path + ppos, block); > + ret = ext4_ext_binsearch_idx(inode, path + ppos, block); > + if (ret < 0) > + goto err; > path[ppos].p_block = ext4_idx_pblock(path[ppos].p_idx); > path[ppos].p_depth = i; > path[ppos].p_ext = NULL; ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero 2022-08-05 14:00 ` [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero Luís Henriques 2022-08-11 17:24 ` Luís Henriques @ 2022-08-12 2:33 ` Baokun Li 2022-08-12 9:22 ` Luís Henriques 1 sibling, 1 reply; 7+ messages in thread From: Baokun Li @ 2022-08-12 2:33 UTC (permalink / raw) To: Luís Henriques, Theodore Ts'o, Andreas Dilger Cc: wenqingliu0120, linux-ext4, linux-kernel, zhangyi (F), yebin10, yukuai (C), Baokun Li 在 2022/8/5 22:00, Luís Henriques 写道: > When walking through an inode extents, the ext4_ext_binsearch_idx() function > assumes that the extent header has been previously validated. However, > there are no checks that verify that the number of entries (eh->eh_entries) > is non-zero. And this will lead to problems because the EXT_FIRST_INDEX() > and EXT_LAST_INDEX() will return garbage and result in this: > > [ 135.245946] ------------[ cut here ]------------ > [ 135.247579] kernel BUG at fs/ext4/extents.c:2258! > [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP > [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4 > [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 > [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 > [ 135.256475] Code: > [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246 > [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 > [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c > [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c > [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024 > [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 > [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 > [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0 > [ 135.277952] Call Trace: > [ 135.278635] <TASK> > [ 135.279247] ? preempt_count_add+0x6d/0xa0 > [ 135.280358] ? percpu_counter_add_batch+0x55/0xb0 > [ 135.281612] ? _raw_read_unlock+0x18/0x30 > [ 135.282704] ext4_map_blocks+0x294/0x5a0 > [ 135.283745] ? xa_load+0x6f/0xa0 > [ 135.284562] ext4_mpage_readpages+0x3d6/0x770 > [ 135.285646] read_pages+0x67/0x1d0 > [ 135.286492] ? folio_add_lru+0x51/0x80 > [ 135.287441] page_cache_ra_unbounded+0x124/0x170 > [ 135.288510] filemap_get_pages+0x23d/0x5a0 > [ 135.289457] ? path_openat+0xa72/0xdd0 > [ 135.290332] filemap_read+0xbf/0x300 > [ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40 > [ 135.292192] new_sync_read+0x103/0x170 > [ 135.293014] vfs_read+0x15d/0x180 > [ 135.293745] ksys_read+0xa1/0xe0 > [ 135.294461] do_syscall_64+0x3c/0x80 > [ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0 > > Unfortunately, __ext4_ext_check() only verifies that eh->eh_entries doesn't > exceed eh->eh_max. And since an empty leaf seems to be a valid value in > same cases, adding this extra check there isn't an option. > > This patch simply adds the check directly in ext4_ext_binsearch_idx() and > propagates this error so that the kernel doesn't hit this BUG_ON() in > ext4_ext_determine_hole(). > > Link:https://bugzilla.kernel.org/show_bug.cgi?id=215941 > Signed-off-by: Luís Henriques<lhenriques@suse.de> > --- > fs/ext4/extents.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > Hi! > > This bug is easily reproducible using the filesystem image provided -- > it's just a matter of mounting it and run: > > $ cat /mnt/foo/bar/xattr Hi Luís, yeah, that's a good catch! > Anyway, I hope my analysis of the bug is correct -- the root cause seems > to be an extent header with an invalid value for in eh_entries, which will > later cause the BUG_ON(). > > Cheers, > -- > Luís But there's a little bit of a deviation in your understanding of the problem, so the patch doesn't look good. The issue is caused by the contradiction between eh_entries and eh_depth. Therefore, we need to check the contradiction instead of adding a judgment to ext4_ext_binsearch_idx. So the right fix is to add a check to __ext4_ext_check like: diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index c148bb97b527..2dfd35f727cb 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -460,6 +460,10 @@ static int __ext4_ext_check(const char *function, unsigned int line, error_msg = "invalid eh_entries"; goto corrupted; } + if (unlikely((eh->eh_entries == 0) && (depth > 0))) { + error_msg = "contradictory eh_entries and eh_depth"; + goto corrupted; + } if (!ext4_valid_extent_entries(inode, eh, lblk, &pblk, depth)) { error_msg = "invalid extent entries"; goto corrupted; In this way, we can fix this issue and check for header exceptions before calling ext4_ext_binsearch_idx. Thanks! -- With Best Regards, Baokun Li ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero 2022-08-12 2:33 ` Baokun Li @ 2022-08-12 9:22 ` Luís Henriques 0 siblings, 0 replies; 7+ messages in thread From: Luís Henriques @ 2022-08-12 9:22 UTC (permalink / raw) To: Baokun Li Cc: Theodore Ts'o, Andreas Dilger, wenqingliu0120, linux-ext4, linux-kernel, zhangyi (F), yebin10, yukuai (C) On Fri, Aug 12, 2022 at 10:33:20AM +0800, Baokun Li wrote: > 在 2022/8/5 22:00, Luís Henriques 写道: ... > > This bug is easily reproducible using the filesystem image provided -- > > it's just a matter of mounting it and run: > > > > $ cat /mnt/foo/bar/xattr > > Hi Luís, > yeah, that's a good catch! > > Anyway, I hope my analysis of the bug is correct -- the root cause seems > > to be an extent header with an invalid value for in eh_entries, which will > > later cause the BUG_ON(). > > > > Cheers, > > -- > > Luís > But there's a little bit of a deviation in your understanding of the > problem, > so the patch doesn't look good. > The issue is caused by the contradiction between eh_entries and eh_depth. Ah! This makes a lot of sense and I can confirm this is exactly what happens in both bugzilla images. Thanks a lot for your feedback! > Therefore, we need to check the contradiction instead of adding a judgment > to ext4_ext_binsearch_idx. > So the right fix is to add a check to __ext4_ext_check like: > > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > index c148bb97b527..2dfd35f727cb 100644 > --- a/fs/ext4/extents.c > +++ b/fs/ext4/extents.c > @@ -460,6 +460,10 @@ static int __ext4_ext_check(const char *function, > unsigned int line, > error_msg = "invalid eh_entries"; > goto corrupted; > } > + if (unlikely((eh->eh_entries == 0) && (depth > 0))) { > + error_msg = "contradictory eh_entries and eh_depth"; > + goto corrupted; > + } > if (!ext4_valid_extent_entries(inode, eh, lblk, &pblk, depth)) { > error_msg = "invalid extent entries"; > goto corrupted; > > In this way, we can fix this issue and check for header exceptions before > calling ext4_ext_binsearch_idx. Awesome, I'll send out v2 with the suggested change. It makes sense to have this check and it should fix both bugs. On the other hand, I still wonder wether the extra check in my original patch is correct or not. I spent a good amount of time trying to find out if eh_entries can be 0 at that point (in ext4_ext_binsearch_idx()) and couldn't find a situation where it could. And running the fstests with that check didn't show any problem. But yeah, my understanding of the whole code is far from perfect. Cheers, -- Luís ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 215941] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image 2022-05-04 19:42 [Bug 215941] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon 2022-08-05 14:00 ` [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero Luís Henriques @ 2022-10-04 9:14 ` bugzilla-daemon 2022-10-04 19:48 ` bugzilla-daemon 2 siblings, 0 replies; 7+ messages in thread From: bugzilla-daemon @ 2022-10-04 9:14 UTC (permalink / raw) To: linux-ext4 https://bugzilla.kernel.org/show_bug.cgi?id=215941 Luis Henriques (lhenriques@suse.de) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lhenriques@suse.de --- Comment #1 from Luis Henriques (lhenriques@suse.de) --- I think that, with commit 29a5b8a137ac ("ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0") merged, this bug can be closed. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 215941] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image 2022-05-04 19:42 [Bug 215941] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon 2022-08-05 14:00 ` [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero Luís Henriques 2022-10-04 9:14 ` [Bug 215941] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon @ 2022-10-04 19:48 ` bugzilla-daemon 2 siblings, 0 replies; 7+ messages in thread From: bugzilla-daemon @ 2022-10-04 19:48 UTC (permalink / raw) To: linux-ext4 https://bugzilla.kernel.org/show_bug.cgi?id=215941 Theodore Tso (tytso@mit.edu) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |tytso@mit.edu Resolution|--- |CODE_FIX --- Comment #2 from Theodore Tso (tytso@mit.edu) --- Indeed, thanks for the patch! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-10-04 19:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-04 19:42 [Bug 215941] New: FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon 2022-08-05 14:00 ` [PATCH] ext4: fix bug in extents parsing when number of entries in header is zero Luís Henriques 2022-08-11 17:24 ` Luís Henriques 2022-08-12 2:33 ` Baokun Li 2022-08-12 9:22 ` Luís Henriques 2022-10-04 9:14 ` [Bug 215941] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_determine_hole() when mount and operate on crafted image bugzilla-daemon 2022-10-04 19:48 ` bugzilla-daemon
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.