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

Open
#1,023 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.