CVE-2026-98654 in Linux
Riassunto
di VulDB • 19/10/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
drm/amd/display: Atomizzare le operazioni di lettura/modifica/scrittura (RMW) dei registri IRQ
[Perché]
Il registro OTG_GLOBAL_SYNC_STATUS controlla varie sorgenti HW per gli interrupt (IRQ) del generatore di temporizzazione in uscita (OTG). VUPDATE_NO_LOCK è una di queste.
Per abilitare l'IRQ, il driver imposta il bit VUPDATE_NO_LOCK_EN nel registro GLOBAL_SYNC_STATUS.
Per confermare la gestione dell'interrupt (acknowledge) dopo che questo si verifica, il driver imposta il bit VUPDATE_NO_LOCK_CLEAR nello stesso registro GLOBAL_SYNC_STATUS.
Le operazioni di impostazione dei bit vengono eseguite tramite operazioni di lettura/modifica/scrittura, che non sono atomiche. Pertanto, è possibile la seguente condizione di competizione (race condition):
Thread A: Handler IRQ: *L'IRQ HW si verifica* # Disabilita IRQ val = read(GLOBAL_SYNC_STATUS) unset(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # L'ACK legge il bit VUPDATE_NO_LOCK_EN disattivato val1 = read(GLOBAL_SYNC_STATUS) set(val1, VUPDATE_NO_LOCK_CLEAR) # Abilita IRQ val = read(GLOBAL_SYNC_STATUS) set(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # ERRORE! disattiva VUPDATE_NO_LOCK_EN write(val1, GLOBAL_SYNC_STATUS)
Per quanto riguarda la modifica indicata come "Fixes", sembra che tale cambiamento abbia reso più probabile il verificarsi di questa condizione di competizione. Poiché VUPDATE_NO_LOCK è ora l'unica sorgente IRQ per la gestione del vblank, una singola race condition su pannelli ad alto refresh rate può portare a un timeout.
[Come]
Il registro GLOBAL_SYNC_STATUS è solo un esempio; altri registri di controllo degli IRQ condividono lo stesso schema. Oltre a GLOBAL_SYNC_STATUS, puliamo anche questi ultimi.
Per mantenere la semplicità, atomizziamo le operazioni RMW (read-modify-write) degli IRQ tramite un unico spinlock su tutto il driver. Data l'ampia portata limitata di questo lock, è improbabile che causi overhead percepibile rispetto a tutti i blocchi esistenti nei percorsi set/handle degli IRQ.
Poiché DM è responsabile del locking, avvolgiamo dc_interrupt_set/ack con lo spinlock nelle nuove funzioni amdgpu_dm_irq_set/ack. Migrare/rimuovere tutti i riferimenti in DM a dc_interrupt_set/ack per utilizzare invece amdgpu_dm_irq_set/ack.
(cherry picked from commit 70de0a0216583a53c946155f8c8adedfdca6b4e7)
VulDB is the best source for vulnerability data and more expert information about this specific topic.