UBUNTU-CVE-2026-99204: Use After Free
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 debugstateprint() walks reco.nodedata and formats their fields. The formatter holds dlm->spinlock, but the recovery participant list is protected by dlmrecostatelock. In particular, dlmdestroyrecoveryarea() detaches the list under dlmrecostatelock 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 debugstateprint() with dlmrecostatelock, matching the existing list writers. This also serializes the traversal against listaddtail() 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 dlmrecostatelock, 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 debugstateopen+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, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x93/0xd0 printreport+0xce/0x630 ? debugstateopen+0x1169/0x12d0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x20e/0x420 ? debugstateopen+0x1169/0x12d0 kasanreport+0xe0/0x110 ? debugstateopen+0x1169/0x12d0 debugstateopen+0x1169/0x12d0 ? pfxdebugstateopen+0x10/0x10 fullproxyopenregular+0x193/0x310 dodentryopen+0x595/0x12d0 ? pfxfullproxyopenregular+0x10/0x10 vfsopenconsume+0xd1/0x400 ? srsoaliasreturnthunk+0x5/0xfbef5 pathopenat+0x18d0/0x2020 ? pfxpathopenat+0x10/0x10 dofileopen+0x21e/0x470 ? pfxdofileopen+0x10/0x10 ? rawspinunlock+0x23/0x40 ? srsoaliasreturnthunk+0x5/0xfbef5 ? allocfd+0x3a6/0x6b0 dosysopenat2+0xf4/0x1b0 ? pfxdosysopenat2+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? fput+0x5b5/0xa60 x64sysopenat+0x136/0x1e0 ? pfxx64sysopenat+0x10/0x10 dosyscall64+0x114/0x620 entrySYSCALL64afterhwframe+0x77/0x7f [Register dump omitted.] </TASK> Allocated by task 880: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasankmalloc+0xaa/0xb0 kmalloccachenoprof+0x28d/0x610 dlmremasterlocks+0x147/0x1d90 dlmdorecovery+0xde1/0x1580 dlmrecoverythread+0x109/0x300 kthread+0x351/0x460 retfromfork+0x659/0x940 retfromforkasm+0x1a/0x30 Freed by task 880: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x5f/0x80 kfree+0x308/0x580 dlmdestroyrecoveryarea+0x285/0x460 dlmremasterlocks+0x17c4/0x1d90 dlmdorecovery+0xde1/0x1580 dlmrecoverythread+0x109/0x300 kthread+0x351/0x460 retfromfork+0x659/0x940 retfromforkasm+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.]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Protect recovery participant traversal and field reads in debug_state_print() with dlm_reco_state_lock, making the existing lock available through dlmcommon.h. Release dlm->spinlock after formatting the other domain state and before acquiring dlm_reco_state_lock so the two locks are not nested.
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
A debugfs read must run concurrently with OCFS2 DLM recovery-area teardown. The race occurs when debug_state_print() traverses recovery participant records while dlm_destroy_recovery_area() detaches and frees those records.
Which systems are in scope?
The affected software list includes Ubuntu linux, linux-fips, linux-aws, linux-azure, linux-gcp, linux-oracle, linux-aws-fips, and linux-azure-fips kernel packages. Exposure specifically involves the OCFS2 DLM debugfs state-reading path.
How can administrators reduce exposure before updating?
Avoid concurrent access to the OCFS2 DLM debugfs state output during recovery-area initialization or destruction. The issue is in the debugfs reader, so limiting access to or use of that diagnostic interface reduces the opportunity for the race.