UBUNTU-CVE-2026-98226: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: mm, swap: fix SWAPUSAGEOFFLISTBIT collision with real usage count SWAPUSAGEOFFLISTBIT is embedded in the si->inusepages usage counter, and is meant to sit above any value that counter can reach. However, it is defined from BITSPERTYPE(atomict), 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. swapusageinpages() 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 trytounuse() takes its "if (!swapusageinpages(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 swapusagesub() see the flag where there is only count, and call addtoavaillist(). It clears the bit with fetchand(~SWAPUSAGEOFFLISTBIT), leaving the stored count 4 TiB below the real one, and calls plistadd() on a device that is already listed, tripping the WARNON(!plistnodeempty(node)) in plistadd() and linking the node a second time. Change the definition of SWAPUSAGEOFFLISTBIT to be based on atomiclongt instead. Note that the usage counter field itself is of this same type, so it is still a valid bit.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Change SWAP_USAGE_OFFLIST_BIT to use the width of atomic_long_t so the off-list flag is above all values the si->inuse_pages usage counter can reach.
Linux kernel swap subsystem SWAP_USAGE_OFFLIST_BIT = Define it based on atomic_long_t rather than BITS_PER_TYPE(atomic_t)
Event History
Frequently Asked Questions
Which systems are most likely to encounter this condition?
The collision is described for systems using 4 KiB pages when a swap device's real in-use page count reaches 4 TiB. The affected Ubuntu kernel package families listed are linux-riscv, linux-realtime, linux-hwe-edge, linux-azure, linux-gcp, linux-azure-fde, linux-gke, and linux-aws-5.0.
Is it safe to run swapoff on a heavily used affected swap device?
Swapoff is unsafe if the raw usage count is exactly 2^30 pages: the masked usage value becomes zero and try_to_unuse() can tear down the device while pages remain swapped out. The description states that the remaining swapoff teardown does not abort, which can cause those pages to be lost.
How might administrators recognize that the counter has crossed the problematic range?
On a 4 KiB-page system, /proc/swaps can report Used as 4 TiB lower than the real usage once the real count has the colliding bit set. A reported zero value can also represent a raw usage count of exactly 2^30 pages, rather than an empty swap device.