CVE-2026-90266: btrfs: zoned: don't force read-only on transient -EAGAIN from reloc merge
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: don't force read-only on transient -EAGAIN from reloc merge
On a zoned FS, btrfsdelayedrefsrsvrefill() returns -EAGAIN whenever the over-committed metadata plus the zoneunusable bytes exceeds the usable size in a metadata block-group to avoid heavy over-commit of metadata and early ENOSPC in one transaction.
If this happens while doing reclaim, the transaction is getting aborted.
Treat -EAGAIN as a soft, retryable condition in case of block-group reclaim.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the described btrfs zoned fix: on zoned FS, do not force read-only on transient -EAGAIN from reloc merge; instead treat -EAGAIN as a soft, retryable condition so the transaction is not aborted during reclaim.
Linux kernel (btrfs zoned filesystem) btrfs_delayed_refs_rsv_refill() handling of -EAGAIN = treat -EAGAIN as soft, retryable during reclaim (especially for block-group transient -EAGAIN from reloc merge)
Event History
Frequently Asked Questions
Which systems are affected by this condition?
The issue applies to Linux kernel systems using a zoned Btrfs filesystem. It is triggered during block-group reclaim when metadata over-commitment plus zone-unusable space exceeds the usable size of a metadata block group.
What operational impact can occur?
A transient -EAGAIN returned by btrfs_delayed_refs_rsv_refill() during reclaim can abort the transaction and force the filesystem read-only. This can interrupt writes even though the condition is intended to be retryable.
What should happen if the condition is encountered?
During block-group reclaim, -EAGAIN should be treated as a soft, retryable condition rather than an error that aborts the transaction. The provided stable-kernel references identify the resolved behavior.