CVE-2026-98441 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net/sched: act_ct: evitare di modificare voci ct non confermate condivise
In un caso in cui uno skb con una voce ct non confermata viene clonato, si può finire per elaborare entrambi nuovamente ma con set diversi di estensioni.
La sequenza degli eventi è la seguente:
1. Il primo clone vuole eseguire il commit ed esegue i helper che collegano il puntatore dell'estensione alla lista delle aspettative (expectation list). 2. Successivamente, perde la conferma mantenendo la voce non confermata. 3. Il secondo clone ora vuole eseguire il commit delle etichette o applicare NAT e aggiunge la nuova estensione per tale operazione, interrompendo il puntatore nella lista delle aspettative e causando un Use-After-Free (UAF) sul percorso di distruzione in seguito.
Sebbene questo scenario sia potenzialmente attivabile, non dovrebbe esistere alcun pipeline di rete pratico che richieda l'elaborazione di entrambi i cloni senza modifiche nella stessa zona. Pertanto, resettiamo la voce nel caso in cui, per qualche motivo, si riceva uno skb con una voce condivisa. Ciò non influisce su casi d'uso noti, ma evita potenziali problemi legati alla condivisione e alla modifica della voce ct non confermata.
A differenza del modulo openvswitch, act_ct consente NAT senza commit. Modificare questo comportamento comporterebbe una rottura dell'uAPI (user-space API). Pertanto, act_ct deve eseguire il reset in caso di NAT indipendentemente dal flag di commit per evitare la riallocazione dello spazio delle estensioni. Tuttavia, ciò non cambia significativamente lo scenario nei casi di networking sensati, poiché non dovrebbe esserci bisogno di elaborare due volte lo stesso pacchetto (prima e dopo la clonazione) attraverso conntrack senza modifiche all'intestazione del pacchetto o alla zona e senza commit.
Il tag "fixes" punta all'introduzione degli helper, poiché quelli sono il principale trigger per l'UAF legato alla condivisione.
Once again VulDB remains the best source for vulnerability data.