[bug report] amdgpu/TTM: NULL/UAF deref in ttm_resource_manager_next during hibernation swapout (ttm_device_prepare_hibernation) on Phoenix APU

[Bernardo <bernardomagri21@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4844 bytes --]

Dear maintainers,

Please find the bug report below. Thanks!

Cheers,
BM


## Summary
Intermittent kernel oops (NULL/near-NULL deref) during hibernation 
*entry*, in the
TTM GPU-memory eviction path invoked by amdgpu's freeze callback
(ttm_device_prepare_hibernation -> ttm_bo_swapout -> LRU walk ->
ttm_resource_manager_next). The oops occurs in the device-freeze phase, 
before the
hibernation image is written, so the next boot reports "PM: Image not 
found (code -22)"
and the session is lost. On my machine oops=panic is set, so it 
escalates to a full
panic+reboot, but the underlying event is the NULL-deref oops shown below.

## Hardware
- Lenovo ThinkPad T14s Gen 4 (MT 21F8CTO1WW), BIOS R2EET46W 1.27 
(2025-09-24)
- CPU/APU: AMD Ryzen 7 PRO 7840U (Phoenix)
- GPU: integrated Radeon 780M, gfx_v11_0, PCI 1002:15bf (rev dd), 
subsystem 17aa:50d8
   - amdgpu reports "VRAM: 1024M ... (1024M used)" — UMA carve-out, no 
discrete VRAM
- Storage: NVMe; root on LUKS+BTRFS; hibernation to a BTRFS swapfile 
(resume_offset set)

## Kernel
- 7.1.4 (vanilla upstream; distro build tag "#1-NixOS PREEMPT(lazy)")
- Taint: G O. The out-of-tree modules loaded are ddcci, ddcci_backlight, 
acpi_call,
   v4l2loopback — none appear in the backtrace and none touch TTM; the 
taint is unrelated.

## Frequency / trigger
Intermittent: 2 failures out of 5 hibernation attempts over 5 days (3 
clean successes
with "PM: hibernation: hibernation exit"). Reproduces on both `systemctl 
hibernate` and
systemd suspend-then-hibernate. Not correlated with a config change — 
fails and succeeds
on the same kernel. The intermittency is consistent with a race 
dependent on GPU buffer
residency at freeze time (see analysis).

## Backtrace (from efi-pstore; consoles were already suspended, so this 
is what was captured)
PM: hibernation: hibernation entry
...
PM: hibernation: Allocated 12299604 kbytes in 7.45 seconds (1650.95 MB/s)
Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
printk: Suspending console(s) (use no_console_suspend to debug)
BUG: kernel NULL pointer dereference, address: 0000000000000268
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 2 UID: 0 PID: 1026678 Comm: kworker/u64:16 Tainted: G    O        
7.1.4 #1-NixOS PREEMPT(lazy)
Hardware name: LENOVO 21F8CTO1WW/21F8CTO1WW, BIOS R2EET46W (1.27 ) 
09/24/2025
Workqueue: async async_run_entry_fn
RIP: 0010:ttm_resource_manager_next+0x94/0x200 [ttm]
RSP: 0018:ffffd0f08294fba0 EFLAGS: 00010202
RAX: ffffd0f08294fc40 RBX: ffff8c0846d306a0 RCX: ffffd0f08294fc40
RDX: ffffd0f08294fc40 RSI: ffffd0f08294fc40 RDI: ffffd0f08294fc40
RBP: ffffd0f08294fc20 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8c029c30ed90 R11: ffff8c04001c6880 R12: 0000000000000020
R13: ffffd0f08294fc40 R14: ffffd0f08294fcc0 R15: 0000000000000260
CR2: 0000000000000268
Call Trace:
  <TASK>
  __ttm_bo_lru_cursor_next+0x60/0x300 [ttm]
  ttm_lru_walk_for_evict+0xde/0x1d0 [ttm]
  ttm_bo_swapout+0x5c/0x80 [ttm]
  ttm_device_prepare_hibernation+0x71/0xb0 [ttm]
  amdgpu_device_evict_resources+0x62/0x80 [amdgpu]
  amdgpu_device_suspend+0x13a/0x230 [amdgpu]
  amdgpu_pmops_freeze+0x1e/0x70 [amdgpu]
  pci_pm_freeze+0x5b/0xe0
  dpm_run_callback+0x51/0x180
  device_suspend+0x1aa/0x5d0
  async_suspend+0x21/0x30
  async_run_entry_fn+0x34/0x150
  process_one_work+0x199/0x390
  worker_thread+0x177/0x2e0
  kthread+0xe2/0x110
  ret_from_fork+0x251/0x330
  ret_from_fork_asm+0x1a/0x30
  </TASK>
Kernel panic - not syncing: Fatal exception   (because this host runs 
with oops=panic)

## Source observations (v7.1.4)
Reading the faulting path in 7.1.4:
- The swapout walk __ttm_bo_lru_cursor_next() 
(drivers/gpu/drm/ttm/ttm_bo_util.c)
   drops the lru_lock (spin_unlock at ~line 1012) and re-acquires it 
(~line 1031). Its
   own comment (~lines 1016-1022) notes that in that window "the 
resource may have been
   freed and allocated again with a different memory type." On the next 
iteration it calls
   ttm_resource_manager_next(&curs->res_curs) (~line 994).
- ttm_resource_manager_next() (drivers/gpu/drm/ttm/ttm_resource.c:690) 
has no guard on
   cursor->man / the LRU state, whereas its sibling 
ttm_resource_manager_first() (:673)
   does (WARN_ON_ONCE(!man)). CR2=0x268 with what looks like a valid 
manager in RBX
   suggests the cursor walked into a freed/reallocated LRU entry rather 
than a NULL
   top-level manager — i.e. a use-after-free/TOCTOU in the lock-dropped 
walk.
- This tree already contains the "move swapped objects off the manager's 
LRU list"
   rework (ttm_resource_is_swapped(), the `unevictable` list), so that 
earlier issue is
   not the cause here.
(These are just pointers for triage; I have not root-caused the exact 
freed object.)

[-- Attachment #2: Type: text/html, Size: 6194 bytes --]