Cloudanix VulnDB

CVE-2026-98226

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug in swap accounting can cause wrong usage numbers and lost data when swap space is used at extremely large scales.

Exploitation
Other
Attacker needs
None
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Bit collision in si->inuse_pages atomic counter where SWAP_USAGE_OFFLIST_BIT (bit 30 from BITS_PER_TYPE(atomic_t)) overlaps real usage counts at 4 TiB on 4 KiB page systems, causing swap_usage_in_pages() to undercount by 4 TiB, erroneous early exits in try_to_unuse(), counter corruption via fetch_and, and duplicate plist_add() calls that trigger WARN_ON.

Why it matters to the business

On high-swap systems, inaccurate usage reporting, swapoff tearing down active devices and losing swapped pages, kernel warnings, and potential system instability or data corruption under sustained heavy swap load.

How an attack unfolds

An attacker fills swap to exceed 4 TiB so the usage counter sets bit 30; subsequent swap_usage_sub() or swapoff paths misinterpret the bit, trigger early teardown, corrupt the plist, and cause lost pages or crashes without any further attacker action required.

How to fix it

Apply the upstream fix that redefines SWAP_USAGE_OFFLIST_BIT using atomic_long_t; rebuild and deploy the corrected kernel image; verify the bit definition after update.

How to confirm the fix worked

Inspect kernel source for SWAP_USAGE_OFFLIST_BIT definition based on atomic_long_t; exercise swapoff at artificially high usage counts and confirm /proc/swaps reports match actual usage without undercount or plist warnings.

Typical attack path

  1. Drive swap usage above 4 TiB via memory pressure or workload
  2. Invoke swapoff or swap_usage_sub() paths
  3. Trigger bit-30 collision leading to masked zero count and plist double-link
  4. Observe data loss on swap device teardown or kernel WARN

How to detect it

Search kernel logs for plist_add WARN_ON messages, unexpected swap usage drops in /proc/swaps, and swapoff teardown events that complete without error while pages remain swapped.

  • WARN_ON(!plist_node_empty(node))
  • swap_usage_in_pages returning value 4 TiB lower than expected
  • swapoff completing with active swapped pages still present

What your security team should do

  • Patch to a kernel containing the atomic_long_t change at the earliest maintenance window
  • Monitor swap usage and avoid sustained loads near or above 4 TiB until patched
  • Add kernel warning detection for plist_add double-link events to SIEM

The record

In the Linux kernel, the following vulnerability has been resolved: mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count SWAP_USAGE_OFFLIST_BIT is embedded in the si->inuse_pages usage counter, and is meant to sit above any value that counter can reach. However, it is defined from BITS_PER_TYPE(atomic_t), so it is bit 30. On a system with 4 KiB pages the flag collides with the usage count once that count reaches 4 TiB. swap_usage_in_pages() masks bit 30 out, so whenever the real count has that bit set, every caller of it reads 4 TiB low: * /proc/swaps understates Used by 4 TiB. * A raw count of exactly 2^30 masks to zero, so try_to_unuse() takes its "if (!swap_usage_in_pages(si)) goto success;" early exit and swapoff tears the device down while pages are still swapped out. Nothing in the rest of swapoff aborts the teardown, so those pages are lost. Independently of swapoff, the collision also corrupts the counter and the plist. On a device in normal use, a free that leaves bit 30 set in the count makes swap_usage_sub() see the flag where there is only count, and call add_to_avail_list(). It clears the bit with fetch_and(~SWAP_USAGE_OFFLIST_BIT), leaving the stored count 4 TiB below the real one, and calls plist_add() on a device that is already listed, tripping the WARN_ON(!plist_node_empty(node)) in plist_add() and linking the node a second time. Change the definition of SWAP_USAGE_OFFLIST_BIT to be based on atomic_long_t instead. Note that the usage counter field itself is of this same type, so it is still a valid bit.

Affected packages

Ecosystem Package Introduced Fixed