CVE-2026-99204

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: 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.]

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.]