DEBIAN-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; expose the existing lock through dlmcommon.h, release dlm->spinlock before acquiring it, and retain the lock while formatting participant records.