CVE-2026-74691 in Linux
Riassunto
di VulDB • 22/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net: thunderbolt: Interrompere i percorsi DMA prima di arrestare gli anelli (rings)
tbnet_tear_down() interrompe entrambi gli anelli e libera i buffer frame prima di chiamare tb_xdomain_disable_paths(). tb_ring_stop() azzera l'indirizzo base dei descrittori dell'anello e tbnet_free_buffers() rimuove la mappatura e libera le pagine in cui risiedono i frame, quindi al momento in cui __tb_path_deactivate_hop() interroga il bit 'pending' del hop (saltatore), tutto ciò che è ancora in transito non ha dove essere smaltito.
La sequenza di teardown era stata mantenuta in questo ordine fin dall'introduzione del driver. Il percorso di setup, tuttavia, no: l'commit ff7cd07f3064 ("net: thunderbolt: Enable DMA paths only after rings are enabled") ha spostato l'abilitazione dei percorsi alla fine di tbnet_connected_work() e ne ha documentato il motivo:
/* Entrambi i login riusciti, quindi abilitare gli anelli, * i percorsi ad alta velocità per la DMA e avviare la coda del dispositivo di rete. * * Nota che abilitiamo le vie della DMA per ultime per assicurarci di aver preparato * l'anello Rx prima che possano arrivare pacchetti in entrata. */
Il teardown non è mai stato aggiornato per corrispondere, quindi gli anelli e i percorsi vengono ora disattivati nello stesso ordine con cui sono stati attivati invece che all'indietro.
Su un router host ASMedia ASM4242 il bit 'pending' non si azzera mai: ogni operazione di teardown consuma l'intero timeout di 500 ms e __tb_path_deactivate_hop() restituisce -ETIMEDOUT. L'aumento del timeout a 5 secondi non aiuta, quindi il hop non è lento nello smaltimento dei dati, ma non lo effettua affatto.
Il malfunzionamento è invisibile al di sopra del core thunderbolt. __tb_path_deactivate_hops() è void e chiama solo tb_port_warn(); anche tb_path_deactivate(), tb_tunnel_deactivate() e __tb_disconnect_xdomain_paths() sono void, e tb_disconnect_xdomain_paths() termina con un "return 0" incondizionato. Pertanto tb_xdomain_disable_paths() segnala il successo e la chiamata netdev_warn() sottostante non viene mai eseguita. Ripetute operazioni di teardown finiscono per disattivare il canale di controllo XDomain, dopo il quale il nodo peer scompare e solo un ciclo di alimentazione (power cycle) riporta in funzione il controller.
La disattivazione dei percorsi prima risolve il problema. Misurato con kretprobes su una versione standard v6.17 senza altri patch applicati, su un collegamento attivo che aveva appena trasportato traffico:
before: __tb_path_deactivate_hop() restituisce 0 per il primo hop, poi -ETIMEDOUT per il secondo dopo 500335 us after: 0 per entrambi, a distanza di 525 us
L'alternanza dei due ordinamenti ABBA su tre livelli di carico, con quattro operazioni di teardown per braccio (arm): ogni operazione di teardown falliva prima della modifica (21 su 21 eseguite), nessuna è fallita dopo la modifica (0 su 24). I bracci "before" sono terminati precocemente perché il collegamento si è interrotto a metà. La stessa ripartizione si osserva quando l'interfaccia viene associata a un bond invece di essere semplicemente disattivata, che è così come ho riscontrato questo problema per la prima volta. Il throughput e la latenza dopo la modifica rimangono invariati.
Gli host i cui router smaltiscono il hop nonostante l'indirizzo base del descrittore obsoleto non vedono differenze funzionali, poiché i percorsi finiscono per essere disattivati in entrambi i casi.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.