CVE-2026-98960

What it actually does

The flaw is a kernel memory leak in the btrfs io_uring implementation: returning -EAGAIN from read or write paths without freeing the btrfs_uring_encoded_data PDU leaves the allocation attached to the command, and io_uring never releases driver-allocated PDUs on ring exit or request cancellation.

Why it matters to the business

Repeated triggering can exhaust kernel memory on systems using btrfs with io_uring, causing performance degradation, process failures, or full system instability; the issue affects recent kernels and requires prompt patching to avoid operational disruption.

How an attack unfolds

An attacker issues io_uring read or write operations against a btrfs filesystem that deliberately return -EAGAIN (for example by hitting non-blocking constraints), leaving the encoded data structure allocated; if the request is later cancelled or the ring is torn down, the memory is never reclaimed, allowing gradual or accelerated exhaustion through repeated submissions.

How to fix it

Upgrade to a kernel containing the fix that ensures btrfs_uring_encoded_data is freed on every -EAGAIN path for both reads and writes; apply the patch that moves allocation after the initial non-blocking attempt and frees on all early exits.

How to confirm the fix worked

Confirm the running kernel contains the commit that frees btrfs_uring_encoded_data on nowait -EAGAIN for reads and before any allocation for writes; test by exercising io_uring read/write workloads that previously returned -EAGAIN and verify no growth in slab or vmalloc usage attributable to the PDU structure.

Typical attack path

1. Identify a target system running a vulnerable kernel with btrfs and io_uring enabled.
2. Submit batches of non-blocking io_uring SQEs targeting btrfs files that trigger -EAGAIN returns before PDU allocation.
3. Cancel or allow the ring to exit while the PDU remains attached.
4. Repeat to accumulate unreleased kernel allocations until memory pressure occurs.

How to detect it

Review kernel logs for repeated btrfs io_uring paths returning -EAGAIN; inspect slabinfo or kmemleak reports for growth in structures sized to btrfs_uring_encoded_data; correlate with processes using io_uring against btrfs mounts.

What your security team should do

• Prioritize kernel updates on all systems using btrfs and io_uring within the next maintenance window.
• Monitor memory usage metrics on affected hosts for unexpected growth in kernel slab caches.
• Disable io_uring for untrusted workloads until patches are deployed if memory pressure is observed.