intel_dp_mst_atomic_check dereferences drm_atomic_get_new_crtc_state() result without NULL check (latent NULL-deref panic, currently masked by earlier drm-core NULL sinks)
Summary
Connector-only atomic transactions (same-value CRTC_ID on an enabled MST connector) make get_new_crtc_state return NULL; the driver derefs to_intel_crtc_state(NULL)->dp_m_n.tu. Today the drm core NULL-crashes first on every reachable shape (drm_atomic_uapi.c:307-316 / drm_atomic_helper.c:223-227 - cross-file leads logged), masking it; becomes a live unpriv-master panic once the core bugs are fixed. NULL-guard fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4770 · 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 1.2 KB | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
DRM master atomic commit {CONNECTOR:mst, CRTC_ID:current} on enabled MST connector -> connector-only state with zero CRTC states -> get_new_crtc_state NULL -> to_intel_crtc_state(NULL)->dp_m_n.tu read at NULL+offset
Evidence (decisive lines)
findings/poc/DF-4770/ (this verdict; source trace in batch record)
Verdict
Latent NULL-deref, hardware-gated: intel_dp_mst_atomic_check derefs drm_atomic_get_new_crtc_state() result for connector-only transactions (same-value CRTC_ID set on an enabled MST connector returns NULL). Today every reachable transaction shape NULL-crashes earlier in the drm core (drm_atomic_uapi.c:307-316 / drm_atomic_helper.c:223-227 - cross-file lead logged for those sinks), masking this driver-side deref; it becomes a live unpriv-master panic the moment the core bugs are fixed. No i915+MST hardware on the QEMU guest. NULL-guard fix authored.
No comments yet.