CVE-2026-90260 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: don't clobber the extent buffer when zeroing it out
On a zoned filesystem a freed-but-still-dirty tree block is written out as zeros (EXTENT_BUFFER_ZONED_ZEROOUT) only to keep the zone write pointer advancing. btree_csum_one_bio() implemented this by memzeroing the extent buffer's own folios before submission.
That destroys the in-memory buffer while it may still be referenced. In particular btrfs_free_tree_block() can run on it afterwards and reads the header to add a delayed reference; once the header has been zeroed it frees bytenr 0 and corrupts the extent tree (the btrfs_header_bytenr(buf) != 0 ASSERT in btrfs_free_tree_block(), or an "unable to find ref" abort). It is flaky and reproduces under fsstress, e.g. generic/461 and generic/013.
Write the zeros to disk from the shared zero page instead and leave the extent buffer content untouched, so any later reference - including the delayed reference from btrfs_free_tree_block() - still sees a valid header. end_bbio_meta_write() now clears writeback on the buffer's own folios, as the bio no longer carries them.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the Linux kernel involves a critical logic error within the Btrfs filesystem implementation for zoned storage devices. Zoned block devices require that writes occur sequentially and cannot overwrite data without first advancing the write pointer through specific mechanisms. To manage this constraint, when a tree block is freed but remains dirty on disk, the system must ensure the zone's write pointer advances even if no new valid data is being written. The original implementation addressed this by zeroing out the extent buffer in memory before submitting it to the storage subsystem, marking it with EXTENT_BUFFER_ZONED_ZEROOUT to signal that zeros should be written to maintain sequential integrity on zoned devices.
The core technical flaw lies in the premature destruction of data structures while they are still actively referenced within the kernel's execution context. Specifically, the function btree_csum_one_bio was responsible for clearing the folios associated with the extent buffer using memzero before submission. This action effectively destroyed the header and other critical metadata residing in that memory region at a time when subsequent operations were expected to read from it. The most significant consequence of this premature zeroing occurs during the cleanup phase, where btrfs_free_tree_block is invoked on the same block.
During the execution of btrfs_free_tree_block, the kernel attempts to process delayed references associated with the freed tree block. This function reads the header of the extent buffer to determine the bytenr for adding a delayed reference entry into the global root's delay ref list. Because the memory had already been zeroed out by the previous bio submission step, btrfs_header_bytenr returns zero instead of the correct physical address. Consequently, the system attempts to free an invalid location with bytenr 0, leading to severe corruption of the extent tree structure. This manifests as a failure in the ASSERT condition checking that the header bytenr is not zero, or results in fatal aborts due to unable to find ref errors when the filesystem tries to resolve references for non-existent blocks.
The operational impact of this vulnerability includes potential data loss and file system instability under heavy load conditions involving frequent allocation and deallocation of tree blocks. The issue is particularly flaky and difficult to reproduce deterministically, often appearing only during stress testing scenarios such as those generated by fsstress tools like generic/461 or generic/013. These tests exercise the filesystem's metadata handling extensively, exposing race-like conditions where memory reuse happens before all references are safely resolved. The corruption of the extent tree can lead to further cascading failures, including inability to mount the file system or loss of accessible data depending on which critical structures were overwritten with invalid zeroed values.
The resolution involves decoupling the mechanism for advancing the zone write pointer from the destruction of in-memory metadata. Instead of zeroing out the actual extent buffer folios before submission, the fix redirects the write operation to use a shared zero page. This allows the storage subsystem to write zeros to disk without altering the contents of the specific extent buffer held in memory by the current thread. Subsequently, end_bbio_meta_write is modified to clear the writeback status on the buffer's own folios independently, acknowledging that the bio no longer carries them for checksumming purposes but leaving their content intact until they are safely freed or reused later under controlled conditions.
From a security and standards perspective, this vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of References to it, as the memory was accessed concurrently by different phases of I/O handling without proper isolation. It also relates to CWE-824, Access of Uninitialized or Released Memory, since the buffer content was invalidated while still logically active within the kernel's reference counting and cleanup logic. In terms of MITRE ATT&CK mapping, this represents a flaw in resource management that could potentially be leveraged for denial-of-service attacks if an attacker can trigger specific allocation patterns on zoned storage devices to induce filesystem corruption or crashes.
Mitigation strategies primarily involve applying the upstream kernel patch that implements the shared zero page approach. For systems unable to update immediately, administrators should monitor logs for extent tree corruption errors and ensure regular backups of critical data stored on Btrfs file systems utilizing zoned block devices such as SMR hard drives or ZNS SSDs. Long-term resilience requires keeping kernel versions updated to benefit from fixes that address race conditions in metadata handling within complex storage stacks.