Mailbox handshake busy-waits up to 12 seconds with mdelay() inside the hard-IRQ .process handler — host/PF can stall the guest in interrupt context per message
Summary
rcv_irq runs synchronously in the amdgpu_irq .process path and calls send_ack - a 12000 x mdelay(1) loop waiting for the host to clear RCV_MSG_VALID; a withholding PF freezes the guest interrupt context 12s per notification at irq-storm rate (watchdog territory). Same loops in init/flr_work contexts are merely sluggish. Guest-hardening grade; defer-ack-to-flr_work fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4756 · 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 1.1 KB | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
host sends FLR notification and never clears RCV_MSG_VALID after guest ACK -> 12s hardirq busy-wait per delivery -> soft-lockup/watchdog guest DoS
Evidence (decisive lines)
findings/poc/DF-4756/ (this verdict; reviewer notes in DF-4754 batch record)
Verdict
Source-certain hardirq stall, hardware-gated: xgpu_vi_mailbox_rcv_irq runs in the amdgpu_irq .process path and synchronously calls xgpu_vi_mailbox_send_ack (mxgpu_vi.c:383) which busy-waits up to VI_MAILBOX_TIMEDOUT(12000) x mdelay(1) = 12s for the host to clear RCV_MSG_VALID - a withholding PF freezes the guest interrupt context 12s per notification, repeatable at irq-storm rate. No SR-IOV AMD hardware on guest. Fix: defer the ack handshake to the already-existing flr_work (peek instead of recv) or cap the inline wait.
No comments yet.