Missing linux-4.19.y stable backports 690e0ec8e63d + 85636167e320: legacy ring buffers still allocated from stolen memory and BAR/WC-mapped on LLC platforms β upstream direction is 'never do this on LLC' (GPU hangs/wedges); DFly carries the pre-fix v4.19 state
Summary
intel_ring_create_vma allocates the ring from stolen memory unconditionally and pin/unpin BAR-map it with no HAS_LLC guard. Upstream added exactly these guards in the 2023 stable pair (690e0ec8e63d + 85636167e320, Cc stable v4.9+) with the rationale that stolen/BAR should never be used for ring buffers on LLC platforms (caching pitfalls -> stale ring reads, lost flushes, GPU hangs). The port took the 2018 stable backports for this file but not this pair, so on every supported LLC platform with stolen memory exposed the CPU->GPU ring path uses the caching-hostile combination. Diff-certain divergence; hardware-gated runtime (no Intel GPU model in QEMU). Three one-line-guard fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4065 Β· 2 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | file | 287 B | β raw | |
| verdict.json | file | 1.2 KB | view raw |
DF-4065 β intel_ringbuffer.c missing 2023 !HAS_LLC stable backports
Low / hardening divergence: rings from stolen + BAR/WC-mapped on LLC platforms. Diff-certain vs linux-4.19.y; hardware-gated runtime. Fix = the upstream pair (690e0ec8e63d, 85636167e320). PoC skipped per contract.
Fix verification
not_testableapply upstream stable pair 690e0ec8e63d + 85636167e320 (three one-line !HAS_LLC guards: stolen alloc gate + pin/unpin BAR-map gates)
source-only (upstream diff)
Confirmed kernel references
Detail
Exploit chain
[]
Evidence (decisive lines)
diff-certain: intel_ringbuffer.c:1096/:1131/:1148 lack the !HAS_LLC guards present in linux-4.19.y
Verdict
source-verified via full diff vs upstream v4.19 and linux-4.19.y; hardware-gated (no Intel GPU model in QEMU)
No comments yet.