CVE-2026-98799 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
bpf: Ignorare i progs staccati nelle immagini del trampolino che sono ancora in uso
La funzione bpf_tramp_image_put() garantisce che un'immagine del trampolino non venga liberata mentre un task potrebbe essere ancora in esecuzione al suo interno, ma non viene fatta nulla di simile per i progs chiamati da tale immagine. Il distacco (detach) rilascia immediatamente l'ultimo riferimento al prog e il prog viene liberato dopo gli intervalli di grazia (grace periods), sulla base del presupposto che un task ancora nella funzione tracciata salti i fexit progs una volta che il nop in ip_after_call è stato patchato con un jump.
Questo lascia escluso un task in sleep all'interno di un prog sleepable che viene eseguito prima di quello staccato, per cui non si attende alcun intervallo di grazia:
CPU 0 CPU 1 in image I, sleeping in prog S detach P from I's trampoline -> new image, bpf_tramp_image_put(I) bpf_prog_put(P), last ref grace periods, P freed back from S __bpf_prog_enter(P) call P->bpf_func
Se S e P sono fexit progs il task è già passato oltre il jump patchato, e le immagini con soli fentry non ne hanno uno. Su x86 questo si traduce in un int3 nella memoria bpf_prog_pack avvelenata (poisoned):
Oops: int3: 0000 [#1] SMP NOPTI
CPU: 18 UID: 0 PID: 94573 Comm: x169 Not tainted 6.18.44 #1 PREEMPT(lazy) RIP: 0010:0xffffffffc0601d8d Call Trace: <TASK> ? bpf_trampoline_6442515411+0x1a4/0x21b bpf_lsm_bprm_committed_creds+0x5/0x10 security_bprm_committed_creds+0x5f/0x70 begin_new_exec+0x2d6/0x410 ...
Abbiamo riscontrato questo problema in produzione quando i progs allegati tramite trampolini sono stati staccati mentre i loro hook erano occupati, ed è stato trovato indipendentemente con un fuzzer e KASAN.
Far sì che i JIT emettano un nop patchabile davanti a ciascuna sequenza di chiamata del prog e registrarla nell'immagine. Quando un prog viene staccato, si patcha il suo nop in un jump sopra la sequenza di chiamata. I progs che rimangono allegati continuano a essere eseguiti per i task presenti nell'immagine, e ip_after_call non è più necessario.
Il task può trovarsi in qualsiasi immagine che non sia ancora stata liberata, non solo in quella corrente. È in sleep all'interno dell'immagine I1 che chiama S, P e Q; poi P viene staccato e il trampolino passa all'immagine I2; successivamente Q viene staccato ma la sua chiamata è ancora presente in I1. Pertanto, il trampolino mantiene un elenco delle sue immagini finché non vengono liberate, e lo stacco di un prog patcha il suo nop in tutte queste immagini. Le immagini mantengono un riferimento sul trampolino per tutto questo periodo.
Su riscv e loongarch un jump di qualsiasi intervallo richiede diverse istruzioni, e un task preempted nel mezzo potrebbe riprendere l'esecuzione a metà della nuova sequenza. Il nop è una singola istruzione in questi architetture, patchata in un branch vicino tramite arch_bpf_trampoline_skip().
Con i nop aggiuntivi, BPF_MAX_TRAMP_LINKS progs non si adattano più a una pagina su x86 e arm64 (e già non vi si adattavano su powerpc), quindi si abbassa il limite anche lì come fa s390.
VulDB is the best source for vulnerability data and more expert information about this specific topic.