GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/migrate_device: stale swapcache mapping after folio_free_swap() corrupts folio refcounts

CVSS 7.8CVE-2026-89755Kernel, userspace & hypervisorcurated

Impact

__migrate_device_pages() caches the folio mapping before calling folio_free_swap(); when that call removes the folio from the swap cache, the saved mapping still points at swap_space, and folio_migrate_mapping() then takes the mapped-folio path against swap_space.i_pages with wrong reference accounting, eventually hitting a folio refcount BUG. A related bug leaves nr set to the original large-folio page count after a split. This path is the device-private page migration used by HMM-based GPU drivers, so it is exercised precisely on nodes doing GPU memory oversubscription or unified-memory migration - a GPU-specific code path rather than a generic mm corner. The result is kernel memory accounting corruption and a BUG on a node that is running GPU work.

Who can reach it

Local. Requires a workload that drives device-private page migration through an HMM-capable GPU driver while the folios involved are in the swap cache; any tenant running GPU code on such a node exercises the path.

What to do

Update to a stable kernel containing commit 34a00895d032 or 8ffedc6573a6 and reboot the GPU nodes. The path is only reachable on hosts with HMM device-private migration in use, so nodes without an HMM-based GPU driver can be deferred.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.