CVE-2026-99204 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
ocfs2/dlm: Protect the recovery list during debugfs reads
Recovery participant records must remain alive while debug_state_print() walks reco.node_data and formats their fields. The formatter holds dlm->spinlock, but the recovery participant list is protected by dlm_reco_state_lock. In particular, dlm_destroy_recovery_area() detaches the list under dlm_reco_state_lock and frees the detached records after releasing it. A concurrent debugfs open can therefore read freed memory.
Protect the participant traversal and field reads in debug_state_print() with dlm_reco_state_lock, matching the existing list writers. This also serializes the traversal against list_add_tail() during recovery-area initialization. Make the existing lock available to the debug code through dlmcommon.h; the lock remains internal to the OCFS2 DLM module.
Release dlm->spinlock after formatting the other domain state and before acquiring dlm_reco_state_lock, so the debug reader does not nest the two locks. Leave recovery list insertion, detachment and freeing unchanged.
KASAN report as below:
BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0 Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896
CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? debug_state_open+0x1169/0x12d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? debug_state_open+0x1169/0x12d0 kasan_report+0xe0/0x110 ? debug_state_open+0x1169/0x12d0 debug_state_open+0x1169/0x12d0 ? __pfx_debug_state_open+0x10/0x10 full_proxy_open_regular+0x193/0x310 do_dentry_open+0x595/0x12d0 ? __pfx_full_proxy_open_regular+0x10/0x10 vfs_open_consume+0xd1/0x400 ? srso_alias_return_thunk+0x5/0xfbef5 path_openat+0x18d0/0x2020 ? __pfx_path_openat+0x10/0x10 do_file_open+0x21e/0x470 ? __pfx_do_file_open+0x10/0x10 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? alloc_fd+0x3a6/0x6b0 do_sys_openat2+0xf4/0x1b0 ? __pfx_do_sys_openat2+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5b5/0xa60 __x64_sys_openat+0x136/0x1e0 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.]
</TASK>
Allocated by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 dlm_remaster_locks+0x147/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30
Freed by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 dlm_destroy_recovery_area+0x285/0x460 dlm_remaster_locks+0x17c4/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff88810662ef80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes inside of freed 32-byte region [ffff88810662ef80, ffff88810662efa0)
[Page and memory-state dumps omitted.]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The Linux kernel's OCFS2 distributed lock manager contains a concurrency vulnerability that results in a use-after-free condition when accessing debugfs interfaces. This flaw arises from an inconsistency in locking mechanisms protecting the recovery participant list during state inspection operations. Specifically, while the formatter function responsible for printing domain state holds the dlm spinlock, it fails to acquire the dlm_reco_state_lock which is required to safely traverse and read fields within the recovery node data structures. The underlying technical flaw involves a race condition where one thread may be in the process of destroying or freeing recovery area records under the protection of dlm_reco_state_lock, while another thread concurrently opens a debugfs file that triggers the state printing routine without holding this specific lock.
The operational impact of this vulnerability is significant as it allows for out-of-bounds memory reads and potential kernel crashes when an unprivileged user with access to debugfs attempts to read distributed lock manager states during active recovery processes. The KASAN report confirms a slab-use-after-free error where the system attempts to read four bytes from a freed 32-byte kmalloc cache region. This occurs because dlm_destroy_recovery_area detaches and frees records while holding dlm_reco_state_lock, but debug_state_open proceeds without this protection, leading to access of memory that has already been returned to the allocator pool. Such vulnerabilities can lead to information disclosure or denial of service through kernel panics depending on timing and memory layout conditions.
To mitigate this issue, the fix involves synchronizing the participant traversal in debug_state_print with dlm_reco_state_lock, thereby matching the protection used by list writers such as during recovery-area initialization via list_add_tail operations. The implementation requires making the existing lock available to debug code through dlmcommon.h while keeping it internal to the OCFS2 DLM module. Additionally, the solution mandates releasing dlm spinlock before acquiring dlm_reco_state_lock to prevent nested locking scenarios that could introduce deadlocks or priority inversion issues. This ensures that recovery list insertions, detachments, and freeing operations remain serialized against concurrent debug reads without altering the fundamental lifecycle management of recovery structures.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free, as it involves accessing memory after it has been freed due to improper synchronization. It also relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding the lack of mutual exclusion for shared data structures during concurrent access patterns. In terms of ATT&CK mapping, this represents a potential avenue for local privilege escalation or system instability if exploited by malicious actors who can trigger debugfs reads concurrently with recovery operations. The vulnerability highlights the importance of consistent locking granularity across all code paths that interact with critical kernel subsystems like distributed lock managers.
The resolution emphasizes strict adherence to existing synchronization primitives rather than introducing new complex locking hierarchies. By ensuring that any read operation on recovery participant records holds dlm_reco_state_lock, the kernel prevents access to memory regions currently being deallocated by other threads managing the recovery process lifecycle. This approach maintains system stability during high-load scenarios where lock remastering and recovery operations are frequent. Developers should verify that all debugfs interfaces interacting with internal DLM state adhere to these locking requirements to prevent similar race conditions in future kernel versions or related subsystems handling distributed consensus data structures.