CVE-2026-98962

What it actually does

On error paths in btrfs_uring_read_extent the iov allocation is not freed because control jumps to out_acct instead of out_free, leaving the kernel memory allocated.

Why it matters to the business

Repeated triggering can slowly exhaust kernel memory on btrfs file systems that use io_uring, raising the chance of performance degradation or forced restarts.

How an attack unfolds

An attacker crafts I/O requests that cause btrfs_uring_read_extent to fail repeatedly; each failure leaks the iov structure until memory pressure forces system impact.

How to fix it

Apply the upstream kernel patch that routes failure cases through out_free so kfree(data->iov) occurs, then rebuild and reboot onto the fixed kernel.

How to confirm the fix worked

Confirm the btrfs source contains the corrected control flow that frees iov on every non-EIOCBQUEUED return from btrfs_uring_read_extent; run targeted stress tests that force read-extent errors and verify no net memory growth.

Typical attack path

1. Identify a btrfs volume and enable io_uring access
2. Submit read requests engineered to hit failure conditions inside btrfs_uring_read_extent
3. Repeat at high volume to accumulate leaked kernel memory

How to detect it

Review kernel memory statistics and slab allocator counters for sustained growth tied to io_uring and btrfs activity; examine audit logs for repeated btrfs read operations that return errors.

What your security team should do

• Prioritize kernel updates on any system exposing btrfs volumes to untrusted io_uring callers
• Add memory-usage monitoring for the btrfs and io_uring code paths
• Disable io_uring for untrusted workloads until patches are deployed