CVE-2025-40209

What it actually does

Early return in btrfs_add_qgroup_relation on invalid qgroup level validation (src >= dst) skips kfree of the caller-preallocated qgroup_list structure, leaving a 64-byte kernel memory leak per failed call because the caller unconditionally nulls the pointer afterward.

Why it matters to the business

Repeated triggering by any local user with write access to a btrfs filesystem can exhaust kernel memory over time, leading to performance degradation or denial of service on Linux systems; the issue affects widely deployed kernel packages with fixes available since late 2025.

How an attack unfolds

An attacker with access to a writable btrfs mount invokes the QGROUP_ASSIGN ioctl repeatedly with src qgroup level greater than or equal to dst; the level check fails before mutex acquisition or error cleanup, the prealloc pointer is nulled by the caller, and the 64-byte allocation is never freed, accumulating leaks until memory pressure occurs.

How to fix it

Upgrade affected Linux kernel packages to the fixed versions: linux-virt and linux-virt-doc to 6.12.25-r0 or later, and kernels containing commit 3412d0e973e8f8381747d69033eda809a57a2581. Reboot after upgrade; no configuration changes are required.

How to confirm the fix worked

Confirm kernel version is at or above the fixed releases; attempt to reproduce the original failing qgroup relation call and verify via slabinfo or kmemleak that the qgroup_list allocation is now released on the error path.

Typical attack path

1. Obtain write access to a btrfs filesystem (mount or container)
2. Prepare qgroup relation arguments where source level >= destination level
3. Call btrfs_ioctl_qgroup_assign (or equivalent userspace tool) in a tight loop
4. Observe gradual kernel memory consumption without corresponding process RSS growth
5. Continue until system-wide memory pressure or OOM events manifest

How to detect it

Look in kernel logs for repeated btrfs qgroup ioctl failures around the time of memory pressure events; use kmemleak or slabtop to watch for accumulating qgroup_list objects that never decrease after failed relation assignments.

What your security team should do

• Prioritize patching btrfs-enabled systems that expose mounts to untrusted users
• Monitor EPSS trend and re-evaluate if exploit code appears
• Restrict unprivileged btrfs mount access via mount options or user namespaces where feasible until patched