radeon_ring_backup() uses the hardware rptr as the first ring index without ptr_mask — bogus GPU/writeback value gives a wild kernel OOB read (panic) during GPU reset
Summary
The loop masks ptr only after the post-increment, so the FIRST ring[ptr] uses the raw u32 - a wedged MMIO readback or hung-GPU writeback (backup runs before the hw reset, on the sick device) reads up to 16GB past the ring BO -> kernel fault during an attacker-induced reset. Identical upstream v4.15/v6.1. Same hw-trust family as DF-4352. mask-before-loop one-liner.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4821 · 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 1.1 KB | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
saturated GPU deadlock -> lockup reset -> backup reads raw rptr > ptr_mask -> ring[ptr] far OOB read -> kernel page fault
Evidence (decisive lines)
findings/poc/DF-4821/ (this verdict)
Verdict
Hardware-gated one-line hardening: radeon_ring_backup uses the hardware rptr (MMIO register or GTT writeback slot) as the FIRST ring index without ptr_mask - masking happens only after the post-increment - so any bogus u32 (wedged MMIO readback, hung GPU scribbling the writeback; backup runs BEFORE the hw reset on the sick device) reads up to 16GB past the kmap'd ring BO -> kernel fault/panic during attacker-induced GPU reset. size itself is masked so the alloc is bounded. Identical upstream (v4.15 and still v6.1). Same hardware-trust family as DF-4352. No radeon GPU on guest; mask-before-loop fix.
No comments yet.