CachyOS / CachyOS/linux-cachyos
vfio_pci_core: NULL pointer dereference in vfio_pci_core_sriov_configure when unbinding vfio-pci from AMD RX 9070 (Navi 48) after VM shutdown
- Dominant language
- Shell
- Stars
- 4.5k
- Forks
- 160
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 1
Description
## Environment
- Distro: CachyOS (rolling, fully updated as of 2026-09-05, no pending packages)
- Kernel: `7.2.2-1-cachyos` — `#1 SMP PREEMPT(full) e429b9d2132c094dcc3a5be7de95f46bd03f9bdb`
- libvirt 12.7.0 / QEMU 11.1.1 / virt-manager 5.1.0
- CPU: Intel Core Ultra 7 265K (Arrow Lake-S)
- Motherboard: ASUS PRIME Z890-P, BIOS 2208 (2025-07-25)
- GPU: AMD Radeon RX 9070 (Navi 48, `1002:7550` rev c3, subsystem Yeston `1ed3:8900`) + HDMI audio `1002:ab40`
- IOMMU: on (platform opt-in, "Intel-IOMMU force enabled due to platform opt in"); GPU and audio function are in clean separate IOMMU groups (18 / 19)
- Guest: Windows 11 (OVMF + Secure Boot), GPU and its audio function attached as libvirt ``
## Summary
Unbinding `vfio-pci` from the RX 9070 causes a deterministic general protection fault (NULL pointer dereference at `+0x460`) in `vfio_pci_core_sriov_configure`, called from `vfio_pci_core_unregister_device()` during the driver remove path. This fires every time libvirt reattaches the GPU after a VM shutdown (managed hostdev), and should also fire on any manual `unbind` from vfio-pci. Reproduced twice, byte-identical traces, on two separate boots.
## Steps to reproduce
1. Pass the GPU through to a VM (or simply bind it to vfio-pci):
```
echo 0000:04:00.0 > /sys/bus/pci/drivers/vfio-pci/bind # device already on vfio, e.g. after VM start
```
2. Shut down the VM, or manually unbind:
```
echo 0000:04:00.0 | sudo tee /sys/bus/pci/drivers/vfio-pci/unbind
```
3. → Oops in `vfio_pci_core_sriov_configure`.
Context in which it was hit: libvirt's managed hostdev reattach after `virsh shutdown` of the Windows 11 guest. The oopsing task is libvirtd's `qemu-event` worker performing the 12-byte write `"0000:04:00.0\n"` to `.../drivers/vfio-pci/unbind` (visible in the userspace `RIP: 0033` frame of the dump, `ORIG_RAX: 1` = write).
## Actual result
Kernel log immediately before the fault (both occurrences):
```
vfio-pci 0000:04:00.0: resetting
vfio-pci 0000:04:00.1: resetting
vfio-pci 0000:04:00.0: reset done
vfio-pci 0000:04:00.1: reset done
Oops: general protection fault, kernel NULL pointer dereference 0x460: 0000 [#1] SMP NOPTI
```
### Occurrence 1 — 2026-09-05 16:39:20 (during first VM shutdown)
```
Oops: general protection fault, kernel NULL pointer dereference 0x460: 0000 [#1] SMP NOPTI
CPU: 12 UID: 0 PID: 21304 Comm: qemu-event Not tainted 7.2.2-1-cachyos #1 PREEMPT(full) e429b9d2132c094dcc3a5be7de95f46bd03f9bdb
Hardware name: ASUS System Product Name/PRIME Z890-P, BIOS 2208 07/25/2025
RIP: 0010:vfio_pci_core_sriov_configure+0x16/0x210 [vfio_pci_core]
Code: cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 89 fb <4c> 8b b7 60 04 00 00 4d 8d be d0 00 00 00 85 f6 0f 84 b6 00 00 00
RSP: 0018:ffffd1a61fd23c08 EFLAGS: 00010246
RAX: 0000000000000004 RBX: 0000000000000000 RCX: 0000000000000003
RDX: ffffffffa84e7d81 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff896b86cff9a0 R08: ffffd1a61fd23bdf R09: 0000000000000030
R10: 0000000000000000 R11: ffffffffc2c7d120 R12: ffffffffc35170f0
R13: ffff896b82daa160 R14: ffff896b82e2e000 R15: ffffffffc3517088
FS: 00007fcedaffd6c0(0000) GS:ffff89713d965000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcee8512378 CR3: 000000016fa52001 CR4: 0000000008f72ef0
PKRU: 55555554
Call Trace:
vfio_pci_core_unregister_device+0x16/0xc0 [vfio_pci_core 561f96005449c10cfcc38db2fe578d9ca75e56cf]
vfio_pci_remove+0x19/0x30 [vfio_pci 17670ce80622d1949dc865d32756dca7fa4d230b]
pci_device_remove.llvm.12216723919884285163+0x45/0xb0
device_release_driver_internal+0x1c2/0x320
unbind_store+0xc9/0xf0
kernfs_fop_write_iter.llvm.10180735450255581822+0x14a/0x190
__x64_sys_write+0x251/0x440
do_syscall_64+0xa6/0x3e0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
---[ end trace 0000000000000000 ]---
```
### Occurrence 2 — 2026-09-05 18:14:06 (second VM shutdown, separate boot, identical)
Same signature: `Oops: general protection fault, kernel NULL pointer dereference 0x460: 0000 [#1] SMP NOPTI`, `RIP: 0010:vfio_pci_core_sriov_configure+0x16/0x210 [vfio_pci_core]`, task `qemu-event`, identical call chain (`unbind_store → device_release_driver_internal → pci_device_remove → vfio_pci_remove → vfio_pci_core_unregister_device → vfio_pci_core_sriov_configure`). Full dump available on request (can attach to this issue).
## Analysis
- Faulting instruction: `mov r14, [rdi+0x460]` with `RDI = 0` — i.e. `vfio_pci_core_sriov_configure()` dereferences a NULL first argument (pci_dev / vdev context), invoked from `vfio_pci_core_unregister_device()+0x16` while the device is being unbound.
- The RX 9070 (Navi 48) has no SR-IOV capability, yet the SR-IOV teardown path is reached unconditionally during vfio device unregistration.
## Aftermath (observed behaviour after the oops)
- Kernel stays alive (no panic), but the GPU is left with **no driver bound**.
- All subsequent sysfs writes targeting the device — `drivers/amdgpu/bind`, `devices/0000:04:00.0/remove`, `bus/pci/drivers_probe`, libvirt `nodedev-reattach` — **hang forever in uninterruptible sleep (D state)**, silently, with no kernel log output. Multiple attempts queue behind the same lock.
- The device can never be reclaimed by amdgpu again; **only a full reboot restores normal operation** (after reboot amdgpu binds normally at boot).
## Notes
- `linux-cachyos-lts 6.18.48` is also installed on this system; not yet tested against this path — happy to test it and report back, as well as any candidate patches.
- Machine is available for further debugging (kdump, ` qemu-event` stack, etc.).
Contributor guide
Research direction
Start at vfio_pci_core_unregister_device() and its call to vfio_pci_core_sriov_configure(), then reproduce the failure by unbinding 0000:04:00.0 from vfio-pci after VM shutdown. Compare the SR-IOV teardown path with the device's lack of SR-IOV capability; done means unbind no longer oopses and the GPU can be rebound to amdgpu without hanging.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100