Cloudanix VulnDB

CVE-2026-98443

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux handles certain file deletion records on XFS filesystems can let the system accidentally reuse old memory or create broken file lists, which may cause crashes or data problems during recovery.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free and inode pointer aliasing in XFS log recovery when handling iunlink buckets, caused by failure to null released pointers, incorrect prev_agino assignment, and improper loop exit handling that can create self-referential unlinked lists or leak inodes.

Why it matters to the business

Systems using XFS may experience kernel instability, crashes, or filesystem corruption during journal recovery after inode unlinking operations, increasing downtime risk on affected Linux deployments.

How an attack unfolds

An attacker with local access triggers inode unlinking sequences that exercise the recovery path; a failed inodegc flush leaves a dangling pointer, enabling subsequent use-after-free access or creation of circular unlinked inode structures during log replay.

How to fix it

Apply the upstream kernel patch that nulls prev_ip after release, prevents ip leaks on flush failure, corrects prev_agino assignment, and ensures prev_ip does not alias ip at loop exit; rebuild and reboot with the fixed kernel.

How to confirm the fix worked

Confirm the corrected xlog_recover_iunlink_bucket function is present in the running kernel source or binary; test by exercising inode unlinking followed by forced log recovery and inodegc failure injection to verify absence of UAF or self-referential inodes.

Typical attack path

  1. Trigger inode deletion to populate unlinked buckets
  2. Force a log recovery that invokes xlog_recover_iunlink_bucket
  3. Induce inodegc flush failure inside the recovery loop
  4. Reuse the freed or aliased inode pointer to corrupt kernel state

How to detect it

Review kernel logs for XFS recovery warnings or inodegc failures around journal replay; inspect for repeated inode operations that coincide with oops or slab corruption reports indicating use-after-free.

What your security team should do

  • Prioritize patching XFS-enabled kernels within the next maintenance window given the recent publication
  • Monitor for upstream stable releases containing the iunlink bucket fix
  • Restrict unprivileged local access on systems where XFS recovery paths cannot be immediately updated

The record

In the Linux kernel, the following vulnerability has been resolved: xfs: fix cursor and pointer handling when recovering iunlink buckets LOLLM pointed out a bug in xlog_recover_iunlink_bucket: 1. We don't null out prev_ip after releasing it, which can lead to UAF problems if the inodegc flush call in the loop fails. at which point I noticed even more bugs: 2. If the inodegc flush inside the loop fails, we also leak @ip. 3. We set prev_agino to agino having already advanced agino, which results in inodes with i_prev_unlinked set to itself. 4. If we exit the bottom of the loop with prev_ip set, then prev_ip aliases ip and we also set its i_prev_unlinked to itself. Bugs 3 and 4 introduce loops into the unlinked list, though these loops don't surface because we immediately flush each unlinked inode after loading it. Fix all of these issues.

Affected packages

Ecosystem Package Introduced Fixed