CVE-2026-98961

What it actually does

Failure paths in btrfs_uring_read_extent() do not consistently release the inode shared lock and extent lock, leaving them held after -ENOMEM or other errors and creating inconsistent locking state across the io_uring read path.

Why it matters to the business

Unpatched kernels may experience deadlocks, stalls, or crashes during io_uring reads on btrfs file systems, disrupting services and requiring emergency reboots with no public exploitation observed to date.

How an attack unfolds

An attacker triggers the error paths (allocation failure or read failure) in btrfs_uring_read_extent() after the locks have been acquired; because the locks are not released on all returns, subsequent operations encounter held locks that can be leveraged for denial of service or, with additional kernel primitives, for privilege escalation via the resulting inconsistent state.

How to fix it

Update to a kernel containing the referenced commit that moves unlock logic into the caller for all failure returns; rebuild and deploy the kernel package, then reboot affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting fs/btrfs/inode.c or the equivalent file for the change that removes unlock calls from out_fail and ensures the caller always unlocks; run regression tests exercising io_uring reads on btrfs with injected errors.

Typical attack path

1. Obtain local code execution on a system using btrfs with io_uring enabled
2. Craft a read operation that reaches btrfs_encoded_read() then btrfs_uring_read_extent()
3. Force an allocation failure or I/O error inside the function
4. Observe or exploit the locks that remain held after the failing return

How to detect it

Review kernel logs for btrfs and io_uring error paths around allocation failures; look for processes stuck in uninterruptible sleep on btrfs inodes or extent locks; no public exploitation artifacts are known.

What your security team should do

• Prioritize patching production btrfs systems within the next maintenance window given the two-day publication age
• Disable io_uring on btrfs volumes if immediate patching is not feasible
• Monitor upstream stable kernel releases for backports of this fix