CVE-2026-98158 in Linuxinformazioni

Riassunto

di VulDB • 25/09/2026

Nel kernel Linux è stata risolta la seguente vulnerabilità:

ppp_async: eliminare il frame errato invece di resettarne lo headroom

ppp_receive_nonmp_frame() antepone un tag di direzione a due byte prima di eseguire i filtri BPF pass/active:

*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG);

Nessun elemento del percorso di ricezione garantisce questi due byte di headroom. Il percorso di errore del frame in process_input_packet() di ppp_async resetta lo headroom di un skb riutilizzato a zero, affermando erroneamente di ripristinarlo allo stato di allocazione fresca - ma uno skb fresco ottenuto da dev_alloc_skb() include NET_SKB_PAD:

err: if (skb) {
/* fa apparire l'skb come appena allocato */ skb_trim(skb, 0); skb_reserve(skb, - skb_headroom(skb)); }

ap->rpkt punta ancora a tale skb, quindi il frame successivo viene riassemblato in esso senza alcuno headroom. Un peer che invia un frame con FCS errato seguito da uno che inizia con ff 03 lascia un solo byte di headroom quando viene aggiunto il tag del filtro; ciò fa sì che l'indirizzo risulti un byte al di sotto di skb->head:

skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev:<NULL> kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt

Il reset dello headroom viola la garanzia NET_SKB_PAD fornita da dev_alloc_skb() al resto del percorso di ricezione. Oltre al panic del filtro sopra descritto, quando è abilitata la compressione CCP, ppp_decompress_frame() passa skb->data - 2 a ->decompress()/->incomp(), che quindi legge fuori dai limiti (out-of-bounds) prima di skb->head per lo stesso motivo.

Invece di ripristinare lo headroom, eliminare il frame errato - come già fa ppp_synctty nel suo percorso di errore - e azzerare ap->rpkt in modo che il prossimo frame venga riassemblato in un nuovo skb con corretto headroom. Questo approccio è più semplice e risolve sia il panic da underflow del filtro (filter under-panic) sia la lettura fuori dai limiti (out-of-bounds read) di CCP.

La versione originale V1 di questa patch creava spazio in ppp_receive_nonmp_frame() utilizzando skb_cow_head(); Eric ha sottolineato che correggere la causa radice nel livello di trasporto è l'approccio corretto.

Trovata tramite fuzzing del percorso di ricezione PPP con un peer mutante su una pty; si tratta di un interessante (remoto) DoS: il root configura PPP, e il peer fornisce due frame che causano panic. Il riproduttore (repro-ppp-skb.c, invariato rispetto alla v1) va in panic in circa un secondo e termina correttamente con questa patch applicata.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Responsabile

Linux

Prenotare

25/09/2026

Divulgazione

25/09/2026

Moderazione

accettato

CPE

pronto

EPSS

0.00000

KEV

no

Attività

molto basso

Fonti

Might our Artificial Intelligence support you?

Check our Alexa App!