Cloudanix VulnDB

CVE-2026-98279

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux storage handling can lock an entire drive or make files unreachable after a security feature runs into space limits.

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

What it actually does

Improper metadata reservation during btrfs verity item cleanup (rollback_verity, drop_verity_items, orphan cleanup) causes -ENOSPC or -EDQUOT errors that force the filesystem read-only or prevent subsequent read-write mounts, even when the limit applies only to one subvolume.

Why it matters to the business

Filesystem becomes unavailable for writes or mounts after verity operations hit quota or space limits, leading to service disruption and potential data inaccessibility until manual recovery.

How an attack unfolds

An attacker with local access enables verity on a subvolume that exhausts its qgroup limit; the subsequent rollback cannot reserve metadata, forcing the filesystem read-only. Orphan cleanup at next mount repeats the failure, leaving unreachable subvolumes and blocking read-write access.

How to fix it

Update the Linux kernel to a version containing the fix that uses btrfs_start_transaction_fallback_global_rsv in btrfs_orphan_cleanup, drop_verity_items, and rollback_verity. Reboot and verify the filesystem mounts read-write after the update.

How to confirm the fix worked

Confirm the kernel version includes the btrfs transaction fallback change, then test enabling verity on a quota-limited subvolume followed by normal mount and write operations without forcing read-only state.

Typical attack path

  1. Obtain local access to a system using btrfs with qgroups enabled
  2. Trigger enable_verity on a subvolume that hits the qgroup limit
  3. Force rollback_verity or orphan cleanup to attempt metadata reservation
  4. Observe filesystem transition to read-only or mount failure on next RW attempt

How to detect it

Review kernel logs for btrfs errors containing -ENOSPC or -EDQUOT during verity rollback or orphan cleanup, and check for unexpected RO transitions or failed RW mounts on btrfs volumes.

What your security team should do

  • Prioritize kernel updates on all btrfs systems using verity or qgroups
  • Monitor for sudden read-only transitions or mount failures on btrfs volumes
  • Test verity enablement under quota limits in staging before production rollout

The record

In the Linux kernel, the following vulnerability has been resolved: btrfs: handle lack of space when cleaning up verity items When enable_verity() hits the qgroup limit, rollback_verity() needs its own metadata reservation. When the qgroup limit or lack of space refuses the rollback, the whole filesystem is forced read-only even though the qgroup limit was for one subvolume only. Also orphan cleanup at the next mount fails the same way, so the leftover items are never removed: with -EDQUOT the subvolume stays unreachable, and with -ENOSPC on a full filesystem the next read-write mount fails. Start transactions with btrfs_start_transaction_fallback_global_rsv() in btrfs_orphan_cleanup(), drop_verity_items() and rollback_verity(). Those calls only delete items and free the space in the end, so they may use the global reserve and skip the qgroup limit, which avoids -ENOSPC and -EDQUOT.

Affected packages

Ecosystem Package Introduced Fixed