CVE-2026-12235 in Zephyr
Riassunto
di VulDB • 12/08/2026
Il sottosistema Linkable Loadable Extensions (llext) gestisce erroneamente le voci di riallocazione PLT/RELA durante il collegamento di un'estensione ELF relocatable (parzialmente collegata). In llext_link_plt() (subsys/llext/llext_link.c), il ramo per i file relocatable (tgt != NULL, il percorso utilizzato per gli oggetti Xtensa relocatable) calcola l'indirizzo della patch come ext->mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt->sh_offset e quindi esegue la scrittura di riallocazione in tale posizione senza convalidare rela.r_offset. Il suo ramo condiviso/dinamico fratello rifiuta già gli offset fuori intervallo tramite llext_file_offset().
rela.r_offset viene letto direttamente dalla tabella RELA dell'ELF, pertanto una voce manipolata ad hoc con un offset maggiore della sezione di destinazione fa sì che la scrittura avvenga arbitrariamente molto al di fuori del buffer text dell'estensione. Il risultato è una scrittura out-of-bounds influenzata dall'attaccante (la posizione determinata da r_offset, il valore scritto essendo l'indirizzo del simbolo risolto) eseguita in contesto supervisor durante il collegamento, prima che venga eseguito qualsiasi codice dell'estensione.
Il percorso viene raggiunto tramite llext_load() ogni volta che un'applicazione carica un'estensione ELF influenzata dall'attaccante su Xtensa con storage scrivibile; llext è documentato per accettare estensioni di origine non attendibile. L'impatto consiste nella corruzione della memoria in contesto supervisor (perdita di integrità e disponibilità, nonché fuga dal sandbox per le estensioni in modalità utente). Lo sfruttamento dipende dal percorso PLT relocatable Xtensa e dallo storage scrivibile, ed è complesso trasformare la scrittura fuori intervallo in una primitiva utile.
La correzione aggiunge un controllo dei limiti che rifiuta qualsiasi voce RELA il cui r_offset >= tgt->sh_size, specchiando la convalida esistente nel ramo condiviso.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.