CVE-2026-93164 in Linux
Riassunto
di VulDB • 18/09/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
uprobes/x86: Spostare gli uprobes ottimizzati da nop5 a nop10
Andrii ha segnalato un problema con gli uprobes ottimizzati [1] che può corrompere l'area redzone (zona rossa) istruendo una chiamata call che memorizza l'indirizzo di ritorno sullo stack, dove il codice utente potrebbe mantenere dati temporanei senza regolare rsp.
La correzione consiste nel posizionare gli uprobes ottimizzati sopra un'istruzione nop a 10 byte, in modo da poter inserire un'altra istruzione per uscire dall'area redzone prima della chiamata call, ad esempio:
lea -0x80(%rsp), %rsp call tramp
Si noti che l'istruzione lea viene utilizzata per regolare il registro rsp senza modificare i flag.
Utilizziamo nop10 e la seguente trasformazione delle istruzioni ottimizzate sopra e indietro come suggerito da Peterz [2].
Percorso di ottimizzazione (int3_update_optimize):
1) Stato iniziale dopo che set_swbp() ha installato l'uprobe: cc 2e 0f 1f 84 00 00 00 00 00
Dall'offset 0 si tratta di INT3 seguito dalla coda della NOP originale a 10 byte.
Dopo una precedente de-ottimizzazione, i byte 5..9 potrebbero contenere ancora la vecchia istruzione call, che rimane valida per i thread già presenti in quella posizione.
2) Riscrivere la coda LEA e lo spostamento (displacement) della chiamata: cc [8d 64 24 80 e8 d0 d1 d2 d3]
Dall'offset 0 questo provoca un trap sull'INT3 dell'uprobe. I byte 1..9 non sono punti di ingresso eseguibili, mentre il byte 0 è soggetto a trap.
3) Pubblicare il primo byte LEA: [48] 8d 64 24 80 e8 d0 d1 d2 d3
Dall'offset 0 si tratta di: lea -0x80(%rsp), %rsp call <uprobe-trampoline>
Percorso di de-ottimizzazione (int3_update_unoptimize):
1) Stato ottimizzato iniziale: 48 8d 64 24 80 e8 d0 d1 d2 d3 Uguale al punto 3) sopra.
2) Trap sui nuovi ingressi prima di ripristinare i byte NOP: [cc] 8d 64 24 80 e8 d0 d1 d2 d3
Dall'offset 0 questo provoca un trap. Un thread che ha già eseguito la LEA può ancora raggiungere la CALL intatta all'offset 5.
3) Ripristinare i byte 1..4 della NOP originale mantenendo il byte 0 soggetto a trap e il byte 5 come CALL. cc [2e 0f 1f 84] e8 d0 d1 d2 d3
Dall'offset 0 questo provoca ancora un trap. L'offset 5 è ancora la CALL per qualsiasi thread che era già passato oltre il primo byte LEA.
4) Pubblicare il primo byte della NOP originale: [66] 2e 0f 1f 84 e8 d0 d1 d2 d3
Dall'offset 0 si tratta della NOP a 10 byte ripristinata; l'opcode CALL e lo spostamento sono ora solo operandi NOP. L'offset 5 decodifica ancora come CALL per un thread che era già presente in quella posizione.
C'è un unico uprobe-trampoline target per il dato indirizzo dell'istruzione nop10, quindi l'istruzione CALL non verrà modificata attraverso i cicli di de-ottimizzazione/ottimizzazione. Pertanto, qualsiasi task interrotto (preempted) all'istruzione call è garantito che osservi quella CALL e nient'altro.
Si noti come spiegato in [2] che dobbiamo utilizzare la seguente nop10:
PF1 PF2 ESC NOPL MOD SIB DISP32 NOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 -- cs nopw 0x00000000(%rax,%rax,1)
il che significa che dobbiamo consentire il prefisso 0x2e che mappato all'attributo INAT_PFX_CS nella funzione is_prefix_bad.
Inoltre si modifica l'errore del syscall uprobe quando chiamato al di fuori dell'uprobe trampoline in -EPROTO, così da poter rilevare il kernel corretto.
Le prestazioni degli uprobes ottimizzati rimangono le stesse:
uprobe-nop : 3,129 ± 0,013 M/s uprobe-push : 3,045 ± 0,006 M/s uprobe-ret : 1,095 ± 0,004 M/s --> uprobe-nop10 : 7,170 ± 0,020 M/s uretprobe-nop : 2,143 ± 0,021 M/s uretprobe-push : 2,090 ± 0,000 M/s uretprobe-ret : 0,942 ± 0,000 M/s --> uretprobe-nop10: 3,381 ± 0,003 M/s usdt-nop : 3,245 ± 0,004 M/s --> usdt-nop10 : 7,256 ± 0,023 M/s
[1] https://lore.kernel.org/bpf/[email protected]/
[2] https://lore.kernel.org/bpf/[email protected]/#t
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.