Look up another CVE · open CVE-2026-90260 in the interactive tracker
CVE-2026-90260
btrfs: zoned: don't clobber the extent buffer when zeroing it out
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem fs/btrfs. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90260 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/btrfs/disk-io.c
fs/btrfs/extent_io.c
- What this is
- BTRFS FILE SYSTEMMAINTAINERS section matched on fs/btrfs/ · linux-btrfs@vger.kernel.org · Maintained
- Kernel module
- btrfs
Check it on the machine
grep -w CONFIG_BTRFS_FS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w btrfsPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_BTRFS_FS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/btrfs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.8 | 6.18.52 | 92484ad014f2 |
| 6.8 | 7.2.6 | 98e3747587f9 |
| 6.8 | 7.3 | db4b9eefc8ee |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The trigger is local VFS syscalls on a mounted zoned btrfs: unlink → btrfs_unlink() → btrfs_del_items() → btrfs_clear_buffer_dirty() sets EXTENT_BUFFER_ZONED_ZEROOUT, then fsync → btrfs_sync_file() → btree_writepages() → write_one_eb() → btree_csum_one_bio(). No network protocol carries the data that causes the clobber.
- AC:LAttack complexity, low
- The attacker drives both sides: unlink/write churn that sets ZONED_ZEROOUT in btrfs_clear_buffer_dirty() while leaving DIRTY set, and fsync or btrfs_btree_balance_dirty() running btree_writepages(). lock_extent_buffer_for_io() drops the tree lock before the memzero, and btrfs_del_leaf() unlocks before btrfs_free_tree_block() reads the header.
- PR:LPrivileges required, low
- btrfs_unlink() and btrfs_sync_file() have no capability check; an unprivileged user with write access on the already-mounted zoned volume can COW-free tree blocks and kick metadata writeback (fsync or the btrfs_btree_balance_dirty() at the end of btrfs_unlink()).
- UI:NUser interaction, none
- The attacker performs the unlink/write/fsync sequence themselves on files they can write; this is a runtime COW/writeback race on a legitimate zoned btrfs (reproduced by fsstress generic/461 and generic/013), not a crafted image a victim must mount.
- S:UScope, unchanged
- The clobbered extent-buffer folios and the bad delayed refs stay inside this mount's btrfs metadata in the host kernel; there is no KVM/Xen guest-to-host, IOMMU, or sandbox boundary crossing.
- C:NConfidentiality impact, none
- btree_csum_one_bio() calls memzero_extent_buffer(eb, 0, eb->len), which memset_extent_buffer() restricts to that buffer's own folios via check_eb_range(); the overwrite is zeros, not an out-of-bounds read or kernel-pointer leak.
- I:HIntegrity impact, high
- After the header is zeroed, btrfs_free_tree_block() queues a BTRFS_DROP_DELAYED_REF with owning_root=btrfs_header_owner(buf)==0 and level=btrfs_header_level(buf)==0, so __btrfs_free_extent() applies a mismatched backref to the shared extent tree and corrupts metadata for every file on the volume.
- A:HAvailability impact, high
- The mismatched delayed ref hits abort_and_dump() → btrfs_abort_transaction(-EUCLEAN) → __btrfs_handle_fs_error() → btrfs_set_sb_rdonly(), forcing the whole filesystem read-only; with CONFIG_BTRFS_ASSERT, ASSERT(btrfs_header_bytenr(buf) != 0) in btrfs_free_tree_block() panics.