CVE-2026-98963 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
btrfs: always return -EIOCBQUEUED after btrfs_uring_read_extent_endio
If all bios finish before btrfs_encoded_read_regular_fill_pages() returns, it calls btrfs_uring_read_extent_endio() and previously returned the I/O status. A negative errno then made btrfs_uring_read_extent() unlock and free while btrfs_uring_read_finished() did the same again.
Return -EIOCBQUEUED so only the deferred path cleans up.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in the Linux kernel's Btrfs filesystem implementation involves a race condition within the asynchronous I/O handling logic, specifically concerning the interaction between btrfs_uring_read_extent and its completion callback. This issue arises when all block input/output operations complete before the function btrfs_encoded_read_regular_fill_pages returns control to the caller. In this specific timing scenario, the kernel invokes btrfs_uring_read_extent_endio prematurely or in a manner that leads to inconsistent state management regarding resource cleanup. The core technical flaw lies in how error codes are returned and processed during this asynchronous operation sequence. Previously, if an error occurred, the function would return a negative errno value directly. This direct return path triggered immediate unlocking and freeing of resources within btrfs_uring_read_extent. However, because the I/O operations had already completed, the completion handler btrfs_uring_read_finished was also scheduled or executed to perform its own cleanup duties.
This dual execution of cleanup routines results in a double-free vulnerability. When both the initial error handling path and the deferred completion path attempt to release the same memory structures or locks, it leads to undefined behavior that can corrupt kernel memory pools. Such corruption is particularly dangerous as it may lead to system crashes, denial of service conditions where the affected node becomes unstable, or potentially more severe exploitation vectors if an attacker can manipulate the timing to trigger this race condition reliably. The double-free scenario undermines the integrity of the kernel's internal data structures related to file extent handling and asynchronous I/O contexts, creating a significant stability risk for systems relying on Btrfs with io_uring enabled.
From a classification perspective, this vulnerability aligns with CWE-415 Double Free, which describes situations where memory is freed more than once, leading to heap corruption or other security issues. It also relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, as the root cause is a race condition between different execution paths accessing shared resources without proper synchronization guarantees in this specific edge case. In terms of MITRE ATT&CK mapping, while not an exploit technique itself, the underlying flaw could be leveraged for privilege escalation or denial of service if exploited by local users with access to io_uring interfaces, falling under categories related to resource exhaustion and kernel exploitation techniques that target memory management subsystems.
The resolution implemented in this patch addresses the issue by modifying the return value logic within btrfs_uring_read_extent_endio. Instead of returning a negative errno which triggers immediate cleanup in the caller context, the function now consistently returns -EIOCBQUEUED. This specific error code signals to the io_uring subsystem that the I/O request has been queued for deferred processing rather than completed immediately. By enforcing this return value, the kernel ensures that only the deferred completion path, managed by btrfs_uring_read_finished, is responsible for unlocking and freeing resources. This eliminates the race condition by guaranteeing a single point of cleanup execution, thereby preventing double-free errors and maintaining memory integrity during high-concurrency asynchronous read operations on Btrfs volumes.
To mitigate this vulnerability in environments where patching may not be immediately feasible, administrators should monitor system logs for kernel panics or oops messages related to btrfs or io_uring subsystems. Disabling io_uring usage for critical workloads until the update is applied can reduce exposure, although this impacts performance characteristics of applications relying on asynchronous I/O. The primary and most effective mitigation remains applying the latest kernel updates that include this specific fix from the Btrfs maintainers. Regularly updating to stable kernel releases ensures that such race conditions in complex subsystems like filesystem drivers are addressed promptly by upstream developers who have deep expertise in these low-level concurrency mechanisms.