CVE-2026-80804

What it actually does

Failure to restore NOFS context on the error path of xfs_trans_roll after __xfs_trans_commit failure leaves the new transaction without nofs protection, creating a circular lock dependency between xfs_nondir_ilock_class and fs_reclaim.

Why it matters to the business

Linux systems using XFS may experience deadlocks or hangs under memory pressure or transaction errors, reducing availability; low EPSS and absence from KEV indicate limited immediate operational risk 25 days after publication.

How an attack unfolds

An attacker with local access triggers repeated XFS transaction commit failures while memory reclaim runs, acquiring the inode lock and fs_reclaim lock in opposing order to induce deadlock; no named threat actors or ransomware use reported.

How to fix it

Apply the upstream fix that unconditionally calls xfs_trans_set_context before the error check in xfs_trans_roll; upgrade to a kernel containing the resolution once released.

How to confirm the fix worked

Inspect the xfs_trans.c source for the reordered xfs_trans_set_context call; reproduce the original failure path under memory pressure and confirm no deadlock occurs.

Typical attack path

1. Obtain local execution on an XFS-mounted system
2. Force conditions that cause __xfs_trans_commit to fail inside xfs_trans_roll
3. Trigger concurrent memory reclaim that acquires fs_reclaim
4. Acquire xfs_nondir_ilock_class from another context to close the circular dependency

How to detect it

Search kernel logs and stack traces for messages referencing xfs_nondir_ilock_class and fs_reclaim occurring together during reclaim or transaction rollback.

What your security team should do

• Track XFS-related kernel updates and schedule rollout on production systems within normal change windows
• Add XFS transaction and reclaim deadlock monitoring to existing kernel panic alerting
• Review XFS usage in high-availability workloads for temporary mitigation options such as memory limits