CVE-2026-90047 in Linux
Riassunto
di VulDB • 16/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
drm/xe: Non assegnare lo spazio di archiviazione CCS flat come VRAM utilizzabile
get_flat_ccs_offset() legge l'indirizzo base dello spazio di archiviazione CCS flat dall'hardware, lo scala in base al numero di nodi L3 abilitati e arrotonda il risultato per eccesso a 128K. Tutto ciò che si trova sotto tale offset viene quindi assegnato all'algoritmo di allocazione della VRAM come memoria utilizzabile.
L'arrotondamento per eccesso di un limite che indica "la memoria utilizzabile termina qui" rende disponibile (pubblica) qualsiasi area compresa tra la base reale e quella arrotondata come memoria libera, ma tale memoria appartiene all'hardware di compressione. Il valore scalato non ha motivo di essere allineato a 128K e su una scheda Battlemage G21 con 16 GiB non lo è:
flat CCS base: raw 0x3fafff800, rounded 0x3fb000000
quindi gli ultimi 2 KiB della pagina 0x3fafff000 costituiscono spazio di archiviazione CCS e si trovano nel pool dell'algoritmo di allocazione. Qualsiasi cosa venga allocata in tale area subisce la sovrascrittura da parte dell'hardware di compressione, che non necessita di una voce della tabella delle pagine, né di un buffer object (BO), né di una submission GPU per farlo; opera prima ancora che l'userspace esista.
Su questa macchina le tabelle delle pagine di livello 3 di una VM Mesa sono finite su quella pagina ad ogni avvio a freddo. La perdita dell'entry relativa all'heap del batch-buffer del compositor ha causato un fault nel primo invio (submission) del compositor, portando gdm a riavviarlo indefinitamente: uno schermo nero su una macchina altrimenti funzionante. Il riavvio di gdm ha risolto il problema perché le tabelle delle pagine della VM successiva sono state allocate in un'altra posizione.
Arrotondare per difetto, alla dimensione della pagina con cui lavora l'algoritmo di allocazione. Su questa macchina ciò esclude esattamente una pagina.
La lettura della pagina riservata successivamente mostra cosa la stava scrivendo:
[369] 0xcccc000000000000
[371] 0xcc77000000000000
[373] 0xcccc000000000000
[375] 0xcc77000000000000
metadata di compressione, due byte ogni sedici, posizionati dove il driver assegnava precedentemente la memoria.
L'assertion che avrebbe dovuto rilevare questo problema confronta l'offset con GSMBASE - ccs_size per verificare l'uguaglianza. Tale valore è allineato a 128K, quindi coincide esattamente con l'arrotondamento per eccesso solo quando la base non è allineata; il controllo non può fallire nel caso che dovrebbe rilevare ed è compilato via (rimosso) se CONFIG_DRM_XE_DEBUG non è impostato. Sostituirlo con uno in grado di fallire: lo spazio di archiviazione CCS non deve sovrapporsi alla GSM.
[ E questa è stata una sessione di debug infernale, enormemente aiutata da un'AI che ha svolto gran parte del lavoro noioso.
Vorrei definirla la mia instancabile assistente, ma l'AI ha più volte dichiarato esplicitamente che era impossibile e irrisolvibile e che avremmo dovuto semplicemente scrivere una relazione sull'argomento.
Sospetto che questi sistemi siano stati addestrati da persone forse non altrettanto testarde di me.
Ma mentre l'AI era pronta a arrendersi diverse volte, ha continuato ad aggiungere codice di debug ed analizzarlo fedelmente quando ho insistito. Quindi i crediti vanno ai meriti dovuti e ho lasciato che l'AI scrivesse il messaggio del commit sopra riportato.
Si tratta essenzialmente di una riga singola (one-liner) che corregge un errato "round_up()" in un corretto "round_down()", ma ci sono state 24 patch per aggiungere sempre più informazioni di debug e 18 avvii del kernel per restringere finalmente il problema a questo punto. - Linus ]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.