Cloudanix VulnDB

CVE-2026-98445

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A rare memory shortage during certain XFS filesystem repair tasks on Linux could cause the system to lose track of disk space or shut down unexpectedly.

Exploitation
Other
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Memory allocation failure during XFS online repair (xrep_newbt_add_blocks) leaks previously allocated btree blocks because callers cannot undo a transaction and return an error without forcing a filesystem shutdown.

Why it matters to the business

XFS filesystems on Linux may experience unexpected downtime, data inconsistency, or require manual intervention after memory pressure occurs during online repair operations.

How an attack unfolds

An attacker or workload induces memory pressure while XFS online repair is allocating blocks for a new btree; the failed allocation leaves the filesystem in an inconsistent state that either leaks space or crashes the filesystem because the transaction cannot be rolled back cleanly.

How to fix it

Update to a Linux kernel containing the NOFAIL allocation change for the ~48-byte btree space reservation object in XFS repair code; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the kernel source contains the NOFAIL allocation for the new btree reservation; run xfs_repair under memory-pressure test conditions and verify no block leaks or shutdowns occur.

Typical attack path

  1. Trigger memory exhaustion on a system running XFS with online repair enabled
  2. Initiate an XFS online repair operation that calls xrep_newbt_add_blocks
  3. Cause the small btree reservation allocation to fail
  4. Observe leaked blocks or forced filesystem shutdown

How to detect it

Review kernel logs for XFS transaction errors or shutdown messages during repair; inspect dmesg and syslog for allocation failure traces in xrep_newbt paths; no widespread exploitation indicators exist.

What your security team should do

  • Prioritize kernel updates on all XFS hosts within the next maintenance window
  • Enable memory-pressure monitoring and XFS repair logging to detect similar conditions
  • Test repair workloads in staging under constrained memory before production deployment

The record

In the Linux kernel, the following vulnerability has been resolved: xfs: don't let memory failures leak blocks and kill repairs LOLLM complains that a memory allocation failure in xrep_newbt_add_blocks results in online repair leaking blocks that were previously allocated to write a new btree, but the problem is worse than that -- a limitation of the codebase is that the callers cannot undo the transaction /and/ return the error -- either you undo all changes and commit the transaction, or you error out and the filesystem goes down. However, the new btree space reservation object isn't that big (~48 bytes). Let's just do a NOFAIL allocation and the problem goes away.

Affected packages

Ecosystem Package Introduced Fixed