Cloudanix VulnDB

CVE-2026-98269

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's handling of certain file operations on btrfs storage could leave the filesystem in a broken state if an error occurs at the wrong moment.

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

What it actually does

Missing transaction abort on inode update failure during btrfs hole punching or reflinking leaves dropped file extent items unaccounted for, allowing a committed transaction to create persistent metadata inconsistency.

Why it matters to the business

Linux systems using btrfs risk silent filesystem corruption or data inconsistency after certain file operations encounter errors, potentially causing application failures, recovery downtime, or data loss.

How an attack unfolds

A local attacker induces an error during inode update in hole-punch or reflink paths so the transaction commits without abort, leaving extent metadata inconsistent; no named threat actors or ransomware campaigns are associated.

How to fix it

Upgrade to a Linux kernel containing the btrfs transaction-abort fix; apply vendor-supplied kernel packages as soon as available.

How to confirm the fix worked

Confirm the running kernel contains the commit that adds the transaction abort; run btrfs-specific stress tests exercising error paths in hole punching and reflinking.

Typical attack path

  1. Perform fallocate hole punch or ioctl reflink on btrfs file
  2. Force failure in the subsequent inode update
  3. Allow the transaction to commit without abort
  4. Observe resulting metadata inconsistency on remount or fsck

How to detect it

Review kernel logs for btrfs transaction commit messages without corresponding abort after inode-update failures; inspect dmesg and journalctl for extent-item warnings on remount.

What your security team should do

  • Prioritize kernel updates on all btrfs deployments within the next maintenance window
  • Monitor btrfs error and transaction logs for unexpected commit behavior
  • Test fallback filesystems or snapshots before applying updates in production

The record

In the Linux kernel, the following vulnerability has been resolved: btrfs: abort transaction on failure to update inode for hole punching and reflinking If we fail to update the inode we error out without aborting the transaction, which can result in a persistent inconsistency if after the failure the transaction is committed, as we have dropped file extent items from a range and either punched a hole or insert a new file extent item for that range (for reflinks). So add the missing transaction abort.

Affected packages

Ecosystem Package Introduced Fixed