Cloudanix VulnDB

CVE-2026-89755

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A memory handling mistake in Linux can let someone who already has access to a machine crash it or take full control.

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

What it actually does

Stale folio mapping pointer retained after successful folio_free_swap() causes folio_migrate_mapping() to perform incorrect reference accounting on swap_space.i_pages, resulting in reference count corruption and a BUG trigger.

Why it matters to the business

Local attackers can crash the kernel or escalate privileges on affected Linux systems, causing denial of service, data loss, or full host compromise; low EPSS and absence from KEV indicate limited in-the-wild exploitation so far.

How an attack unfolds

An attacker with local access crafts or triggers device page migration paths that invoke __migrate_device_pages(), ensuring folio_free_swap() succeeds so the saved mapping becomes stale; the subsequent folio_migrate_mapping() call then operates on freed swapcache structures, corrupting folio refcounts and triggering the BUG.

How to fix it

Apply the upstream fix that refreshes the saved mapping after folio_free_swap() and resets nr after large folio splits; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Verify the presence of the mapping refresh and nr reset logic in mm/migrate_device.c; confirm no folio reference count BUGs occur under migration workloads that previously triggered the issue.

Typical attack path

  1. Obtain local user or container access on a vulnerable kernel
  2. Trigger or wait for device page migration involving swapcache folios
  3. Cause folio_free_swap() to succeed while the stale mapping is still cached
  4. Force folio_migrate_mapping() to use the invalid mapped-folio path
  5. Induce reference count underflow or BUG to crash or exploit the kernel

How to detect it

Search kernel logs for folio reference count BUG messages or oops traces originating from mm/migrate_device paths; correlate with swapcache activity and device migration events.

What your security team should do

  • Prioritize patching production kernels that perform device page migration or heavy swap activity
  • Monitor for kernel BUG/oops reports mentioning folio reference counts or migrate_device
  • Restrict untrusted local code execution until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: clear stale mapping after freeing swapcache __migrate_device_pages() reads the folio mapping before calling folio_free_swap(). When folio_free_swap() succeeds, the folio is removed from the swap cache, but the saved mapping still points to swap_space. Passing the stale mapping to folio_migrate_mapping() makes it use the mapped-folio path for a folio that is no longer in swapcache. It can then operate on swap_space.i_pages with invalid reference accounting, eventually triggering a folio reference count BUG. After a successful split, nr still contains the number of pages in the original large folio, although each resulting page is now a separate order-0 folio. Reset nr to 1 so each split folio is processed separately, including its own swapcache removal and mapping lookup. Refresh the saved mapping after folio_free_swap() so the current folio state is used during migration.

Affected packages

Ecosystem Package Introduced Fixed