CVE-2026-93255 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
btrfs: make sure EXTENT_BUFFER_READING is cleared under refs_lock
[FALSE ALERTS]
There is a bug report that the warning inside invalidate_and_check_btree_folios() got triggered during btrfs/298:
BTRFS info (device sdd): first mount of filesystem f9bf732a-a19b-44b9-99a7-614ddff168e2 BTRFS info (device sdd): using crc32c checksum algorithm BTRFS error (device sdd): failed to find fsid cb2fdb42-b638-4f2f-badd-4127467ba674 when attempting to open seed devices BTRFS error (device sdd): failed to read chunk tree: -2 ------------[ cut here ]------------
WARNING: disk-io.c:3342 at invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs], CPU#4: mount/125993
CPU: 4 UID: 0 PID: 125993 Comm: mount Tainted: G W OE 7.1.0-rc7-custom+ #1 PREEMPT(full) Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 Call trace: invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs] (P)
open_ctree+0x1f50/0x23b0 [btrfs]
btrfs_get_tree+0x89c/0xc48 [btrfs]
vfs_get_tree+0x30/0x110 vfs_cmd_create+0x58/0xe8 __arm64_sys_fsconfig+0x39c/0x518 invoke_syscall.constprop.0+0x48/0x120 el0_svc_common.constprop.0+0x40/0xe8 do_el0_svc+0x24/0x38 el0_svc+0x50/0x310 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x198/0x1a0 ---[ end trace 0000000000000000 ]---
BTRFS warning (device sdd): unable to release extent buffer 365985792 owner 3 gen 17 refs 3 flags 0x5
[CAUSE]
In that invalidate_and_check_btree_folios() we wait for the eb to finish its read, then check if it's only held by us and the btree inode.
If not, then do a warning as it may be still held, and could cause problems.
But there is a small window where the check can lead to false alerts:
Thread A (Read endio) | Thread B (Unmount) ----------------------------------+------------------------------------- end_bbio_meta_read() | | The eb has one extra ref held | | by the reader, and has | | EXTENT_BUFFER_READING flag set | invalidate_and_check_btree_folios() | | | |- clear_extent_buffer_reading() | | | | |- wait_on_bit_io(); | | | The EXTENT_BUFFER_READING flag is | | | cleared | | |- if (refcount_read(eb->refs) > 2) | | The eb is held by the read, us | | and btree inode, thus it | | will trigger the warning |- free_extent_buffer() |
[FIX]
Introduce a helper, free_extent_buffer_clear_reading().
If the new parameter, @clear_reading, is set, we will hold the spinlock at the beginning of free_extent_buffer_clear_reading() to make sure the EXTENT_BUFFER_READING flag is cleared inside the same critical section of decreasing refs.
Now free_extent_buffer() will just call free_extent_buffer_clear_reading() with @clear_reading set to false, so no behavior change.
But for end_bbio_meta_read(), it will not clear_extent_buffer_reading() directly, but pass @clear_reading as true.
Then inside invalidate_and_check_btree_folios(), hold the refs_lock before reading refs. So that we eliminate the race window completely.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel's Btrfs filesystem implementation contained a concurrency flaw within its extent buffer management logic, specifically involving the clearing of the EXTENT_BUFFER_READING flag and reference count checks during unmount operations. This vulnerability manifested as false positive warnings in the invalidate_and_check_btree_folios function when attempting to open seed devices or perform certain mount sequences on tainted kernels. The issue arises from a race condition where the state of an extent buffer is not atomically verified against its usage references, leading to incorrect assumptions about whether the buffer is still actively held by other threads. This flaw does not typically result in data corruption or privilege escalation but causes disruptive kernel warnings that can complicate debugging and indicate underlying synchronization issues within the filesystem's I/O handling mechanisms.
The root cause lies in a timing window between two concurrent operations: a read endio thread completing metadata reads and an unmount thread attempting to clean up extent buffers. In this scenario, Thread A clears the EXTENT_BUFFER_READING flag after finishing its read operation, while simultaneously or shortly thereafter, Thread B enters invalidate_and_check_btree_folios during the unmount process. Thread B waits for any ongoing I/O to complete and then checks if the buffer is held only by itself and the btree inode. However, because the clearing of the reading flag and the decrementing of reference counts are not performed under a single lock protection in all code paths, there exists a brief interval where the read endio thread has cleared the flag but not yet released its reference count. Consequently, Thread B observes a reference count greater than two, triggering a warning that falsely suggests the buffer is still improperly held by external entities, even though it is merely in the process of being freed by the reader itself.
This race condition violates fundamental principles of concurrent programming regarding atomicity and lock ordering, aligning with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization Race Condition. The improper synchronization allows one thread to observe an inconsistent state because another thread is in the middle of a multi-step update operation that spans multiple locks or no locks at all. In terms of attack surface and operational impact, this vulnerability primarily affects system stability during filesystem unmounting operations, particularly when dealing with seed devices or complex mount configurations involving checksum algorithms like crc32c. While it does not expose sensitive data directly, the resulting kernel warnings can lead to confusion for administrators and developers attempting to diagnose genuine issues, potentially masking real problems behind noise generated by this false alert mechanism.
The resolution involves refactoring the extent buffer freeing logic to ensure that the EXTENT_BUFFER_READING flag is cleared within the same critical section where reference counts are decremented. A new helper function, free_extent_buffer_clear_reading, was introduced to encapsulate this atomic operation. When invoked with a parameter indicating that reading flags should be cleared, this function acquires the refs_lock at its inception, ensuring that both the state change and the reference count update occur atomically without interruption from other threads. The original free_extent_buffer function continues to operate normally by calling this helper with the flag disabled, preserving backward compatibility for code paths where such atomicity is not required during normal operation. For end_bbio_meta_read, which previously cleared the reading flag separately, it now utilizes this new mechanism to guarantee that no race window exists between clearing the state and releasing references.
To mitigate similar issues in other parts of the kernel or future developments, developers must adhere strictly to lock ordering protocols when modifying shared resource states across multiple threads. It is critical to ensure that any check on a resource's usage count is performed while holding the appropriate synchronization primitive that protects both the reference count and associated state flags. This approach eliminates the possibility of observing intermediate states where a flag has been cleared but references remain, which is the core flaw exploited by this race condition. By enforcing atomicity in these critical sections, the kernel ensures consistent visibility of buffer states across all executing threads, thereby preventing false warnings and maintaining the integrity of filesystem operations during high-concurrency scenarios such as unmounting or mounting complex Btrfs configurations.