CVE-2026-98106: drm/pagemap: Prevent double migration of device pages
In the Linux kernel, the following vulnerability has been resolved:
drm/pagemap: Prevent double migration of device pages
A device-private folio migrated to system memory by a CPU fault can remain reachable through the raw-PFN eviction path until migration finalization drops the source reference.
If eviction selects the same device-private folio during this window, it can attempt to migrate the folio again. The second migration can leave an uncharged folio on an LRU list, causing foliolruveclockirqsave() to retry indefinitely and resulting in a soft lockup and RCU stall.
Mark successfully migrated device-private folios using a low bit of their zonedevicedata before migration finalization. Make both CPU-fault and raw-PFN migration paths skip device-private folios carrying this flag.
Mask the flag when retrieving the drmpagemapzdd pointer and preserve it when a device-private folio is split. Keeping the state on the physical folio also avoids depending on a virtual address that may change before a fault occurs.
v2: - Replace the retired-PFN XArray with an embedded bitmap. (Matthew Brost) - Mark every base page covered by a migrated folio so retirement remains valid if the folio is later split.
v3: - Store the migrated state in a low bit of zonedevicedata instead of adding virtual-range and bitmap tracking to the ZDD. (Matthew Brost) - Mask the flag when retrieving the ZDD and preserve it when splitting a folio. - Drop the pre-existing fixes already covered by Matthew Brost's series: https://patchwork.freedesktop.org/series/171651/
v4: - Advance by the folio size only for migration entries marked with MIGRATEPFNCOMPOUND. (Sashiko)
v5: - Simplify ZDD flag updates and folio iteration. (Matthew Brost) - Skip retired device-private folios in the CPU-fault path. (Matthew Brost) - Preserve flag bits while taking a new ZDD reference for split folios.
v6: - Restore MIGRATEPFNCOMPOUND-aware stepping so non-compound migration entries are processed one at a time. (Sashiko) - Drop the pre-existing fixes already covered by Matthew Brost's series: https://patchwork.freedesktop.org/series/171651/
The lockup was observed as: [10109.860465] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [kworker/u65:5:6557] [10109.860524] Tainted: [S]=CPUOUTOFSPEC, [O]=OOTMODULE [10109.860524] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [10109.860525] Workqueue: xepagefaultworkqueue xepagefaultqueuework [xe] [10109.860644] RIP: 0010:rawspinunlockirqrestore+0x57/0x80 [10109.860655] Call Trace: [10109.860655] <TASK> [10109.860657] foliolruveclockirqsave+0x216/0x220 [10109.860661] ? pfxlruadd+0x10/0x10 [10109.860665] foliobatchmovelru+0xc8/0x450 [10109.860670] ? lockacquire+0xc4/0x2d0 [10109.860674] ? foliobatchaddandmove+0x60/0x2e0 [10109.860677] ? foliomigratemapping+0xa6/0x110 [10109.860679] ? foliomigrateflags+0x13b/0x1b0 [10109.860681] ? pfxlruadd+0x10/0x10 [10109.860683] foliobatchaddandmove+0xe7/0x2e0 [10109.860685] ? dmaiovatryalloc+0xb0/0x140 [10109.860689] folioaddlru+0x64/0x80 [10109.860691] migratedevicefinalize+0x12c/0x270 [10109.860695] migratedevicefinalize+0x10/0x20 [10109.860698] drmpagemapevicttoram+0x185/0x370 [drmgpusvmhelper] [10109.860704] ? drmpagemapevicttoram+0x96/0x370 [drmgpusvmhelper] [10109.860709] xesvmboevict+0x15/0x20 [xe] [10109.860819] ? xesvmboevict+0x15/0x20 [xe] [10109.860921] xebomove+0x107e/0x1570 [xe] [10109.860992] ? xettmttcreate+0x168/0x340 [xe] [10109.861059] ? upread+0x98/0x2b0 [10109.861061] ? lockisheldtype+0xa3/0x130 [10109.861067] ttmbohandlemovemem+0xe8/0x1e0 [ttm] [10109.861075] ttmboevict+0x141/0x1c0 [ttm] [10109.861081] ttmboevictcb+0x9f/0x100 [ttm] [10109.861086] ttmlruwalkforevict+0x84/0x190 [ttm] [10109.861091] ? xettmvrammgrnew+0x258/0x3a0 [xe] [10109.861198] ttmboallocresource+0x219/0 ---truncated---
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the soft lockup?
A device-private folio must first be migrated to system memory by a CPU fault, then be selected again through the raw-PFN eviction path before migration finalization drops the source reference. The second migration can leave an uncharged folio on an LRU list, leading to indefinite retrying and an RCU stall.
Which migration paths need to avoid already migrated device-private folios?
Both the CPU-fault migration path and the raw-PFN migration path must skip device-private folios marked as successfully migrated. The fix stores this state in a low bit of zone_device_data and masks that bit when obtaining the drm_pagemap_zdd pointer.
How does the fix retain protection when a migrated folio is split?
The migrated state is preserved when a device-private folio is split, and every base page covered by a migrated folio is marked. This keeps the retirement state valid even if the folio is split after migration.