CVE-2026-90083 in Linux
Riassunto
di VulDB • 18/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net/sched: act_ife: Operare solo su frame Ethernet
act_ife incapsula/decapsula l'intestazione Ethernet originale e utilizza skb->dev->hard_header_len come lunghezza di tale intestazione. Ciò è corretto solo per i dispositivi Ethernet: su un dispositivo in cui hard_header_len non corrisponde all'intestazione L2 effettivamente estratta (PPP segnala PPP_HDRLEN mentre nulla viene rimosso in ingress), le operazioni skb_push()/skb_pull() in ingresso utilizzano una lunghezza errata e possono causare uno skbuff_under_panic quando lo spazio disponibile nella testata (headroom) è limitato.
IFE è progettato per funzionare esclusivamente con Ethernet: costruisce un'intestazione ethhdr esterna, riscrive h_source/h_dest/h_proto ed esegue eth_type_trans() in fase di decodifica; pertanto, invece di tentare di far funzionare gli offset per tipi di collegamento arbitrari, si devono semplicemente scartare i pacchetti che non trasportano un'intestazione Ethernet.
Il controllo del solo skb->dev->type non è sufficiente. È necessario gestire un caso limite in cui mirred può reindirizzare uno skbuff da un dispositivo non Ethernet a uno Ethernet e, di conseguenza, skb->dev non fornisce informazioni sul framing effettivo dello skbuff: uno skbuff reindirizzato da ppp0 raggiunge il gancio di ingress del target con mac_len pari a 0 e senza alcuna intestazione Ethernet. Pertanto, in fase di ingress si richiede anche che mac_len sia uguale a ETH_HLEN. In uscita (egress) mac_len non viene mantenuto, quindi l'unico parametro disponibile è il tipo del dispositivo; un reindirizzamento errato in questa fase produce un frame malformato anziché una push fuori dai limiti (out-of-bounds), e tale frame risulterebbe comunque malformato sia con che senza IFE.
Questo caso limite non è solo teorico: il reindirizzamento da ppp0 a un veth dotato di azione encode ife sul suo gancio di ingress provoca un panic in assenza di questa patch:
skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728)
Garantendo il framing Ethernet, si utilizza ETH_HLEN al posto di hard_header_len.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.