| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <202511171102228046461@163.com> Date: Mon, 17 Nov 2025 11:02:24 +0800 From: "mowenroot@....com" <mowenroot@....com> To: slava <slava@...eyko.com>, glaubitz <glaubitz@...sik.fu-berlin.de>, frank.li <frank.li@...o.com> Cc: linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>, 1985755126 <1985755126@...com> Subject: Bug Report: Memory Corruption Vulnerability in HFS Node Operations Dear Linux Kernel Maintainers, We are 0rb1t & mowen, and during our analysis of the HFS module in the Linux Kernel, we discovered a bug related to memory corruption in the node operation logic. We would like to report it as a regular kernel bug for resolution. Bug Description ------------------- In the HFS (Hierarchical File System) module of the Linux kernel, we identified an issue with memory corruption within the node operation functions. Specifically, the functions responsible for moving and copying data blocks in HFS B-tree nodes (such as hfs_bnode_move() and hfs_bnode_copy()) lack proper boundary validation when handling node metadata read from disk. This can lead to out-of-bounds memory access when operating on node->page[0], which can result in kernel memory corruption or data corruption. Steps to Reproduce ------------------------ 1. Compile the Linux kernel with HFS filesystem support: CONFIG_HFS_FS=y 2. Create a crafted HFS disk image (using a script or any other method). 3. Mount the crafted image using: mount -t hfs ./disk2.img ./mnt 4. Perform filesystem operations such as mkdir or touch on the mounted filesystem. Expected Behavior --------------------- The kernel should properly handle node metadata without causing memory corruption. Actual Behavior ------------------- When performing operations, the kernel experiences a crash due to a NULL pointer dereference or out-of-bounds memory access. This can lead to a kernel panic or other instability. Kernel Version ------------------- This issue has been observed in kernel versions from v2.6.12 to the latest version. Test Log (example of crash) ------------------------------- [ 45.578488] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 45.581387] #PF: supervisor instruction fetch in kernel mode [ 45.581654] #PF: error_code(0x0010) - not-present page [ 45.582149] PGD 0 P4D 0 [ 45.582752] Oops: 0010 [#1] PREEMPT SMP NOPTI [ 45.583199] CPU: 0 PID: 77 Comm: main Not tainted 6.6.77 #15 [ 45.583469] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 45.583807] RIP: 0010:0x0 [ 45.584587] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 45.584797] RSP: 0018:ffffc9000013fcf0 EFLAGS: 00000046 [ 45.584999] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc9000013fdb8 [ 45.585267] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffff82a0e7e8 [ 45.585658] RBP: 0000000000000000 R08: ffffc9000013fdb8 R09: ffffc9000013fd50 [ 45.585838] R10: 0000000040000000 R11: 0000000000000400 R12: ffffffffffffffe8 [ 45.586003] R13: 0000000000000003 R14: 0000000000000000 R15: ffffc9000013fdb8 [ 45.586323] FS: 0000000005a493c0(0000) GS:ffff88803e200000(0000) knlGS:0000000000000000 [ 45.586585] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 45.586803] CR2: ffffffffffffffd6 CR3: 0000000002a2e000 CR4: 00000000003006f0 [ 45.587138] Call Trace: [ 45.587823] <TASK> [ 45.588205] ? __die+0x1f/0x70 [ 45.588770] ? page_fault_oops+0x7d/0x150 [ 45.588879] ? __switch_to_asm+0x3e/0x70 [ 45.589090] ? finish_task_switch.isra.0+0x7d/0x220 [ 45.589234] ? exc_page_fault+0x69/0x150 [ 45.589402] ? asm_exc_page_fault+0x26/0x30 [ 45.589573] __wake_up_common+0x74/0x140 [ 45.589850] __wake_up_common_lock+0x7e/0xd0 [ 45.590034] wake_up_bit+0x7f/0xa0 [ 45.590207] evict+0x18e/0x2b0 [ 45.590360] ? _atomic_dec_and_lock+0x39/0x60 [ 45.590537] __dentry_kill+0xd1/0x170 [ 45.590793] __fput+0x141/0x290 [ 45.590979] task_work_run+0x58/0x90 [ 45.591218] do_exit+0x537/0x6e0 [ 45.591380] ? hrtimer_interrupt+0x125/0x230 [ 45.591589] do_group_exit+0x2c/0x80 [ 45.591684] __x64_sys_exit_group+0x13/0x20 [ 45.591839] do_syscall_64+0x39/0x90 [ 45.592030] entry_SYSCALL_64_after_hwframe+0x78/0xe2 [ 45.592324] RIP: 0033:0x44fb31 [ 45.592506] Code: Unable to access opcode bytes at 0x44fb07. [ 45.592741] RSP: 002b:00007fff263be0d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 45.593185] RAX: ffffffffffffffda RBX: 00000000004d0290 RCX: 000000000044fb31 [ 45.593535] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 [ 45.593911] RBP: 0000000000000000 R08: ffffffffffffffb8 R09: 0000000005a4a770 [ 45.594094] R10: 000000000000006f R11: 0000000000000246 R12: 00000000004d0290 [ 45.594408] R13: 0000000000000000 R14: 00000000004d1160 R15: 00000000004024d0 [ 45.594645] </TASK> [ 45.594788] Modules linked in: [ 45.595257] CR2: 0000000000000000 [ 45.595663] ---[ end trace 0000000000000000 ]--- [ 45.596024] RIP: 0010:0x0 [ 45.596134] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 45.596359] RSP: 0018:ffffc9000013fcf0 EFLAGS: 00000046 [ 45.596548] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc9000013fdb8 [ 45.596732] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffff82a0e7e8 [ 45.596889] RBP: 0000000000000000 R08: ffffc9000013fdb8 R09: ffffc9000013fd50 [ 45.597299] R10: 0000000040000000 R11: 0000000000000400 R12: ffffffffffffffe8 [ 45.597539] R13: 0000000000000003 R14: 0000000000000000 R15: ffffc9000013fdb8 [ 45.597805] FS: 0000000005a493c0(0000) GS:ffff88803e200000(0000) knlGS:0000000000000000 [ 45.598036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 45.598195] CR2: ffffffffffffffd6 CR3: 0000000002a2e000 CR4: 00000000003006f0 [ 45.598419] note: main[77] exited with irqs disabled [ 45.598800] note: main[77] exited with preempt_count 2 [ 45.599121] Fixing recursive fault but reboot is needed! [ 45.599675] BUG: scheduling while atomic: main/77/0x00000000 [ 45.599944] Modules linked in: [ 45.600197] CPU: 0 PID: 77 Comm: main Tainted: G D 6.6.77 #15 [ 45.600810] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 45.601514] Call Trace: [ 45.601699] <TASK> [ 45.601814] dump_stack_lvl+0x37/0x50 [ 45.601970] __schedule_bug+0x4d/0x60 [ 45.602203] __schedule+0x5e1/0x6b0 [ 45.602307] ? _printk+0x57/0x80 [ 45.602514] do_task_dead+0x3e/0x40 [ 45.602646] make_task_dead+0x128/0x130 [ 45.602840] rewind_stack_and_make_dead+0x17/0x20 [ 45.603078] RIP: 0033:0x44fb31 [ 45.603167] Code: Unable to access opcode bytes at 0x44fb07. [ 45.603401] RSP: 002b:00007fff263be0d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 45.603616] RAX: ffffffffffffffda RBX: 00000000004d0290 RCX: 000000000044fb31 [ 45.603938] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 [ 45.604150] RBP: 0000000000000000 R08: ffffffffffffffb8 R09: 0000000005a4a770 [ 45.604334] R10: 000000000000006f R11: 0000000000000246 R12: 00000000004d0290 [ 45.604645] R13: 0000000000000000 R14: 00000000004d1160 R15: 00000000004024d0 [ 45.604880] </TASK> qemu-system-x86_64: terminating on signal 2 Suggested Fix ------------------- We suggest reviewing and hardening the functions that perform direct operations on node->page[0], including: - hfs_bnode_move() - hfs_bnode_copy() - hfs_bnode_write() - hfs_bnode_clear() The fix should involve: - Validating src, dst, and len against node_size to ensure proper bounds checking. - Ensuring no cross-page memory access occurs. - Adding sanity checks for malformed or forged node metadata, such as the record offset and node_size. Impact ------------------- This issue can cause kernel memory corruption and Denial of Service (DoS) when interacting with a malformed HFS image. Under specific conditions, it may also lead to potential Local Privilege Escalation (LPE). Please let us know if you need further information. We look forward to your assistance in resolving this bug. Best regards, 0rb1t & mowen
Powered by blists - more mailing lists