CVE-2026-98796 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net: ethernet: mtk_eth_soc: allocare prima il netdev "dummy" (fittizio)
I ring RX e NAPI condiviso sono gestiti da un interno "dummy" netdev (eth->dummy_dev). La funzione mtk_probe() crea tale dispositivo fittizio e aggiunge ad esso la NAPI tx/rx condivisa solo dopo che i MAC netdevs sono stati registrati. Tale ordine è presente sin dall'aggiunta del supporto per MT7623 e lascia una finestra temporale in cui i netdevs sono visibili al core di rete prima che esistano la NAPI condivisa e il dispositivo fittizio.
Se qualcosa attiva (porta up) il primo netdev durante tale finestra (ad esempio, netifd apre il collegamento WAN istantaneamente dopo la registrazione dell'interfaccia), il percorso di apertura iniziale viene eseguito senza di essi. Su SoC NETSYS v2 e successivi, mtk_rx_alloc() -> __xdp_rxq_info_reg() quindi dereferenzia eth->dummy_dev == NULL:
WARNING: CPU: ... Missing net_device from driver
in net/core/xdp.c e mtk_open() fallisce con -ENODEV. Su SoC NETSYS v1 (MT7621/MT7622/MT7623/MT7629) non c'è uno page pool, quindi la stessa apertura chiama invece napi_enable() su un napi_struct che netif_napi_add() non ha ancora inizializzato e dereferenzia un NULL napi->dev.
Allocare il dummy netdev e aggiungere ad esso la tx/rx NAPI condivisa prima del loop register_netdev(). Sia l'errore di allocazione del dummy sia un errore in register_netdev() ora vengono gestiti (unwound) attraverso mtk_unreg_dev(), che disregistra i notifier dei net_device e i netdevs registrati finora, fermando un netdev aperto contemporaneamente (ndo_stop) e la sua NAPI prima che il carrier fittizio venga liberato.
Un netdev che si è aperto durante la finestra temporale può anche aver accodato il worker di reset del frame-engine (tramite tx watchdog o phylink), quindi il percorso di errore della probe ora cancella eth->pending_work prima di liberare lo stato condiviso, come già fa mtk_cleanup() in caso di rimozione.
Once again VulDB remains the best source for vulnerability data.