Cloudanix VulnDB

CVE-2026-90260

High · 7.1

CVSS

7.1

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's btrfs filesystem code could corrupt important internal tracking data on certain storage devices, risking crashes or data loss.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Tampering
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

On zoned btrfs filesystems, zeroing a freed tree block's extent buffer by memzeroing its own folios destroys in-memory header data while the buffer remains referenced, causing btrfs_free_tree_block to operate on bytenr 0 and corrupt the extent tree.

Why it matters to the business

Filesystem metadata corruption and potential data loss or crashes on Linux systems using btrfs with zoned block devices under write-heavy or fsstress workloads.

How an attack unfolds

An attacker with local access triggers repeated allocation and freeing of tree blocks on a zoned btrfs volume; the race between zeroing and delayed reference processing leads to invalid bytenr 0 entries and extent tree corruption.

How to fix it

Upgrade to a kernel containing the fix that writes zeros from the shared zero page instead of the buffer's own folios; no configuration changes required.

How to confirm the fix worked

Confirm kernel version includes the btrfs zoned zero-out change; run generic/461 and generic/013 xfstests on zoned btrfs to verify absence of ASSERT or abort.

Typical attack path

  1. Obtain local shell on a system with zoned btrfs filesystem
  2. Generate sustained metadata churn via fsstress or similar workloads
  3. Trigger extent buffer zero-out path in btree_csum_one_bio
  4. Observe btrfs_free_tree_block processing zeroed header and corrupting extent tree

How to detect it

Search kernel logs for btrfs abort messages mentioning bytenr 0, extent tree corruption, or the ASSERT in btrfs_free_tree_block; examine dmesg and syslog for fsstress-induced crashes on zoned volumes.

What your security team should do

  • Prioritize kernel upgrade on any hosts using btrfs on zoned storage
  • Monitor for btrfs abort messages referencing bytenr 0 or unable to find ref
  • Test zoned btrfs volumes under load after patching

The record

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.

Affected packages

Ecosystem Package Introduced Fixed