CVE-2026-23467 in Linux
Riassunto
di VulDB • 15/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
drm/i915/dmc: Correzione di un improbabile dereferenziamento di puntatore NULL durante la fase di probe
intel_dmc_update_dc6_allowed_count() genera un oops quando DMC non è stato inizializzato e, di conseguenza, dmc è NULL.
Ciò si verifica quando il percorso di chiamata è intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() ->
gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), poiché intel_power_domains_init_hw() viene chiamato *prima* di intel_dmc_init().
Tuttavia, gen9_set_dc_state() chiama intel_dmc_update_dc6_allowed_count() in modo condizionale, a seconda degli stati DC6 correnti e target. Durante il probe, il target è disabilitato, ma se DC6 è abilitato, la funzione viene chiamata e si verifica un oops. Apparentemente, è piuttosto improbabile che DC6 sia abilitato durante il probe, poiché non abbiamo mai osservato questo tipo di errore in precedenza.
È anche strano trovare DC6 abilitato all'avvio, poiché ciò richiederebbe il firmware DMC (caricato dal BIOS); la sequenza in cui il BIOS carica il firmware DMC e il driver arresta/rimpiazza il firmware è una sequenza scarsamente specificata e, come tale, è improbabile che sia un comportamento intenzionale del BIOS. È più probabile che il BIOS lasci uno stato HW DC6 abilitato involontariamente (senza effettivamente caricare il firmware DMC richiesto per questo).
Il tracciamento del contatore DC6 consentito funziona solo se l'avvio/arresto del contatore dipende dallo stato DC6 _SW_ (software) rispetto allo stato DC6 _HW_ (hardware) corrente (poiché l'arresto del contatore richiede il contatore DC5 catturato quando il contatore è stato avviato). Pertanto, utilizzare lo stato HW DC6 è errato e porta anche al suddetto oops. Si correggono entrambi i problemi utilizzando lo stato DC6 SW per il tracciamento.
Questa è la versione 2 della correzione inviata originariamente da Jani, aggiornata in base alla discussione iniziale nel Link: sottostante.
(cherry picked from commit 2344b93af8eb5da5d496b4e0529d35f0f559eaf0)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.