CVE-2026-23161

mm/shmem, swap: fix race of truncate and swap entry split

Published Feb 14, 2026 CVSS 3.1 · 7.3 High EPSS < 1% KEV · Not listed
Description
In the Linux kernel, the following vulnerability has been resolved:

mm/shmem, swap: fix race of truncate and swap entry split

The helper for shmem swap freeing is not handling the order of swap
entries correctly. It uses xa_cmpxchg_irq to erase the swap entry, but it
gets the entry order before that using xa_get_order without lock
protection, and it may get an outdated order value if the entry is split
or changed in other ways after the xa_get_order and before the
xa_cmpxchg_irq.

And besides, the order could grow and be larger than expected, and cause
truncation to erase data beyond the end border. For example, if the
target entry and following entries are swapped in or freed, then a large
folio was added in place and swapped out, using the same entry, the
xa_cmpxchg_irq will still succeed, it's very unlikely to happen though.

To fix that, open code the Xarray cmpxchg and put the order retrieval and
value checking in the same critical section. Also, ensure the order won't
exceed the end border, skip it if the entry goes across the border.

Skipping large swap entries crosses the end border is safe here. Shmem
truncate iterates the range twice, in the first iteration,
find_lock_entries already filtered such entries, and shmem will swapin the
entries that cross the end border and partially truncate the folio (split
the folio or at least zero part of it). So in the second loop here, if we
see a swap entry that crosses the end order, it must at least have its
content erased already.

I observed random swapoff hangs and kernel panics when stress testing
ZSWAP with shmem. After applying this patch, all problems are gone.

Analysis

AI-generated

Technical impact

The Linux kernel’s memory‑management subsystem contains a race condition in the shared‑memory (shmem) swap‑freeing routine. The helper obtains the order of a swap entry with xa_get_order outside a lock and later performs an atomic compare‑and‑swap to delete the entry. If the entry is split or otherwise modified between these two steps, the order value becomes stale. The stale order can cause the helper to truncate data beyond the intended end boundary or leave a swap entry uncleared, resulting in kernel memory corruption and potentially a panic when swapoff is called.

Affected Systems

The flaw exists in the Linux kernel itself, specifically in versions 6.19 release candidates rc1 through rc7. Systems running these kernels and utilizing the shmem swap facility are potentially vulnerable.

Risk and Exploitability

The CVSS score of 7.3 indicates a high‑severity impact. The EPSS score is reported as < 1 % and the vulnerability is not listed in the CISA KEV catalog. Exploitation would require a precise race between truncation of a region and modification of a swap entry; such a race is technically possible but practically difficult to trigger from user space. The risk is therefore primarily a denial‑of‑service scenario rather than privilege escalation.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade to a patched Linux kernel release (e.g., 6.19 rc8 or newer) that incorporates the race‑condition fix.
  • If an upgrade is not immediately feasible, disable ZSWAP or set vm.swappiness=0 to reduce use of shmem swap and lower the attack surface.
  • Monitor system logs (dmesg, journalctl) for swapoff hangs or kernel panics and consider applying SELinux/AppArmor profiles to harden the runtime environment.

Generated by OpenCVE AI on April 18, 2026 at 18:02 UTC.

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Ubuntu USN Ubuntu USN USN-8570-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8594-1 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8604-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8605-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8570-2 Linux kernel (Oracle) vulnerabilities
Ubuntu USN Ubuntu USN USN-8669-1 Linux kernel (NVIDIA) vulnerabilities
History
Type Values Removed Values Added
Metrics cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 7.3, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H'}

Type Values Removed Values Added
Weaknesses CWE-362
CPEs cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc7:*:*:*:*:*:*
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: mm/shmem, swap: fix race of truncate and swap entry split The helper for shmem swap freeing is not handling the order of swap entries correctly. It uses xa_cmpxchg_irq to erase the swap entry, but it gets the entry order before that using xa_get_order without lock protection, and it may get an outdated order value if the entry is split or changed in other ways after the xa_get_order and before the xa_cmpxchg_irq. And besides, the order could grow and be larger than expected, and cause truncation to erase data beyond the end border. For example, if the target entry and following entries are swapped in or freed, then a large folio was added in place and swapped out, using the same entry, the xa_cmpxchg_irq will still succeed, it's very unlikely to happen though. To fix that, open code the Xarray cmpxchg and put the order retrieval and value checking in the same critical section. Also, ensure the order won't exceed the end border, skip it if the entry goes across the border. Skipping large swap entries crosses the end border is safe here. Shmem truncate iterates the range twice, in the first iteration, find_lock_entries already filtered such entries, and shmem will swapin the entries that cross the end border and partially truncate the folio (split the folio or at least zero part of it). So in the second loop here, if we see a swap entry that crosses the end order, it must at least have its content erased already. I observed random swapoff hangs and kernel panics when stress testing ZSWAP with shmem. After applying this patch, all problems are gone.
Title mm/shmem, swap: fix race of truncate and swap entry split
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Aug 5, 2026, 12:20 PM
Reserved
Jan 13, 2026, 3:37 PM
Status
Modified
Published
Feb 14, 2026, 4:15 PM
Modified
Jun 17, 2026, 10:21 AM
Severity
Moderate
Public date
Feb 14, 2026, 12:00 AM