CVE-2026-74351: ocfs2: rebase copied fsdlm LVB pointers in locking_state
Greg Kroah-Hartman <[email protected]>
| Newsgroups | org.kernel.vger.linux-cve-announce |
|---|---|
| Message-ID | <2026081559-CVE-2026-74351-7982@gregkh> |
From: Greg Kroah-Hartman <[email protected]> Description =========== In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f The Linux kernel CVE team has assigned CVE-2026-74351 to this issue. Affected and fixed versions =========================== Issue introduced in 2.6.26 with commit cf4d8d75d8aba537a19b313a9364fd08ddbd5622 and fixed in 5.10.261 with commit 185427b5f7a209254c85c18aad5a4a8e009b2f30 Issue introduced in 2.6.26 with commit cf4d8d75d8aba537a19b313a9364fd08ddbd5622 and fixed in 5.15.212 with commit 07aa4a8ebacde3d0ba50f60d2964f274ee7629bc Issue introduced in 2.6.26 with commit cf4d8d75d8aba537a19b313a9364fd08ddbd5622 and fixed in 6.1.178 with commit e037c1250cc90e7aacb002357d1b0399fc65ecfc Issue introduced in 2.6.26 with commit cf4d8d75d8aba537a19b313a9364fd08ddbd5622 and fixed in 6.6.145 with commit 6b38a5b8ee951e5b244e9a3c3d28d0f5e7c51411 Issue introduced in 2.6.26 with commit cf4d8d75d8aba537a19b313a9364fd08ddbd5622 and fixed in 6.12.97 with commit 8614a8f7e81edd34c9f67e454e7024fd12a2a341 Issue introduced in 2.6.26 with commit cf4d8d75d8aba537a19b313a9364fd08ddbd5622 and fixed in 6.18.40 with commit bb44a7690a4d553da705919cf666a80f5ca9011c Issue introduced in 2.6.26 with commit cf4d8d75d8aba537a19b313a9364fd08ddbd5622 and fixed in 7.1.5 with commit 610a0d2a35496738e1472fb0f318d5008a1c634f Issue introduced in 2.6.26 with commit cf4d8d75d8aba537a19b313a9364fd08ddbd5622 and fixed in 7.2-rc1 with commit 93612d48fa42b3d1a637eb9279e15281c611c000 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-74351 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: fs/ocfs2/dlmglue.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/185427b5f7a209254c85c18aad5a4a8e009b2f30 https://git.kernel.org/stable/c/07aa4a8ebacde3d0ba50f60d2964f274ee7629bc https://git.kernel.org/stable/c/e037c1250cc90e7aacb002357d1b0399fc65ecfc https://git.kernel.org/stable/c/6b38a5b8ee951e5b244e9a3c3d28d0f5e7c51411 https://git.kernel.org/stable/c/8614a8f7e81edd34c9f67e454e7024fd12a2a341 https://git.kernel.org/stable/c/bb44a7690a4d553da705919cf666a80f5ca9011c https://git.kernel.org/stable/c/610a0d2a35496738e1472fb0f318d5008a1c634f https://git.kernel.org/stable/c/93612d48fa42b3d1a637eb9279e15281c611c000