dce4/avivo_crtc_do_set_base pin the scanout BO then return -EINVAL on unsupported-format/tiling errors without unpinning — repeatable VRAM pin-exhaustion DoS
Summary
In the !atomic path both set_base functions pin the framebuffer GEM object into VRAM and only afterwards validate the pixel format. The format switches do not cover formats the DRM core happily creates framebuffers with (any registered fourcc - RGB888, XBGR8888, YUV) - the default arm returns -EINVAL with the BO still pinned and the reserve already dropped. Because the modeset aborts, this fb never becomes the CRTC's fb, so neither the old-fb unpin nor crtc_disable will ever unpin it. Each DRM_MODE_SETCRTC with such an fb permanently strands one VRAM pin; repeating exhausts video memory, recoverable only by reboot. Unpin-on-error fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4102 · 2 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | file | 236 B | ↓ raw | |
| verdict.json | file | 945 B | view raw |
DF-4102
Hardware-gated finding - PoC skipped (device absent on audit guest). Source citations in the pass-2 result block.
Fix: unpin under reserve on every error return after the pin (or validate format/tiling before radeon_bo_pin)
Fix verification
not_testableunpin under reserve on every error return after the pin (or validate format/tiling before radeon_bo_pin)
source-only
Confirmed kernel references
Detail
Exploit chain
[]
Evidence (decisive lines)
source-only; full path:line trace in pass-2 result block
Verdict
source-verified; hardware-gated (no BusLogic HBA / no radeon GPU on audit guest)
No comments yet.