Cloudanix VulnDB

CVE-2026-90261

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux storage handling on certain disk types can unexpectedly lock filesystems into read-only mode during busy operations, forcing restarts to recover.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in btrfs zoned metadata writeback allows btree_writepages() to encounter an active block group with unsent IO, causing btrfs_check_meta_write_pointer to return -EAGAIN, which btrfs_write_and_wait_transaction treats as fatal and aborts the transaction, forcing the filesystem read-only.

Why it matters to the business

Intermittent filesystem read-only state during metadata-heavy workloads on zoned storage can interrupt applications, require manual recovery or reboot, and increase operational overhead in environments using Btrfs on zoned devices.

How an attack unfolds

An attacker with local access performs metadata-intensive operations such as relocation or heavy write workloads on a zoned Btrfs filesystem; the ascending writeback walk hits a lower logical block group while an active higher one still has pending IO, the pivot fails under the zoned_meta_io_lock, and the transaction aborts.

How to fix it

Apply the upstream kernel patch that flushes active metadata and system block groups at btree_writepages start under the zoned_meta_io_lock; rebuild and boot the fixed kernel on affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting the btrfs/zoned.c source for the early flush under fs_info->zoned_meta_io_lock; reproduce btrfs/187-style relocation workloads and verify absence of transaction abort messages in dmesg.

Typical attack path

  1. Obtain local shell or unprivileged process on a system using Btrfs on zoned storage
  2. Trigger or sustain metadata-heavy operations that dirty multiple block groups
  3. Force writeback with WB_SYNC_ALL to exercise the btree_writepages path
  4. Induce the active block group pivot failure leading to transaction abort

How to detect it

Search kernel logs (dmesg, journalctl) for Btrfs messages containing "aborting transaction", "btrfs_check_meta_write_pointer", or "zoned_meta_io_lock" around the time of workload-induced writeback; correlate with relocation or commit operations.

  • btrfs_check_meta_write_pointer.*-EAGAIN
  • aborting transaction.*zoned
  • BTRFS: error.*write pointer pivot

What your security team should do

  • Prioritize kernel updates on all systems using Btrfs with zoned block devices
  • Add monitoring for Btrfs transaction abort and read-only transition events
  • Restrict unprivileged local access on systems hosting critical zoned Btrfs volumes until patched

The record

In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: flush active metadata block group at btree_writepages() start btree_writepages() writes the btree inode's dirty metadata in ascending logical address order. On a zoned filesystem only one metadata and one system block group is active for writing at a time, and check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the active block group as writeback moves from one block group to the next. If the active block group sits at a higher logical address than another block group that also holds dirty metadata, the ascending walk reaches the lower one first and, to write it, has to finish the active block group and activate the lower one. It cannot finish a block group that still has unsent IO, and during WB_SYNC_ALL && !for_sync (commit) writeback it deliberately refuses to wait for that IO under fs_info->zoned_meta_io_lock, as that can deadlock. The pivot thus cannot issue the submission itself either, so it gives up: btrfs_check_meta_write_pointer() returns -EAGAIN, which btrfs_write_and_wait_transaction() treats as fatal and aborts the transaction, forcing the filesystem read-only. This happens intermittently under metadata-heavy relocation (e.g. fstests btrfs/187). Flush the active metadata and system block groups at the start of btree_writepages(), under the fs_info->zoned_meta_io_lock it already holds, so they have no unsent IO left and the later pivot can finish them and make forward progress.

Affected packages

Ecosystem Package Introduced Fixed