CVE-2026-89755: mm/migrate_device: clear stale mapping after freeing swapcache
In the Linux kernel, the following vulnerability has been resolved:
mm/migratedevice: clear stale mapping after freeing swapcache
migratedevicepages() reads the folio mapping before calling foliofreeswap(). When foliofreeswap() succeeds, the folio is removed from the swap cache, but the saved mapping still points to swapspace.
Passing the stale mapping to foliomigratemapping() makes it use the mapped-folio path for a folio that is no longer in swapcache. It can then operate on swapspace.ipages 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 foliofreeswap() so the current folio state is used during migration.
Event History
Frequently Asked Questions
What conditions are needed to trigger the issue?
The issue occurs during device-page migration when a folio has swap cache removed successfully and migration subsequently uses a stale saved mapping. It also involves handling of a split large folio, where the page count must be reset so each resulting order-0 folio is processed independently.
What is the observable impact if the vulnerable path is reached?
Migration can operate on swap_space.i_pages using invalid reference accounting after the folio is no longer in swap cache. This can eventually trigger a folio reference count BUG.
How does the fix prevent the failure?
The fix refreshes the folio mapping after folio_free_swap() so migration uses the folio's current state. It also resets nr to 1 after a successful split, ensuring each resulting folio receives its own swap-cache removal and mapping lookup.