CVE-2026-98302 in Linux
Résumé
par VulDB • 06/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: fddi: skfp : correction d'une déréférencement NULL lors de la définition de l'adresse MAC lorsque l'interface est inactive (down)
skfp_ctl_set_mac_address() appelle ResetAdapter() inconditionnellement, sans vérifier netif_running(). ResetAdapter() appelle d'abord card_stop(), qui définit smc->hw.hw_state sur STOPPED, puis mac_drv_clear_tx_queue(), qui parcourt les deux files de transmission :
for (i = QUEUE_S; i <= QUEUE_A0; i++) {
queue = smc->hw.fp.tx[i] ;
... t = queue->tx_curr_get ;
smc->hw.fp.tx[] n'est peuplé que par init_tx(), qui est atteint via skfp_open() à travers init_smt() -> init_fddi_driver() -> init_fplus() -> init_mac() -> init_tx(). La zone privée est allouée et initialisée à zéro par alloc_fddidev(), donc sur une interface qui n'a jamais été activée, les pointeurs de file sont toujours NULL. Le test hw_state au début de mac_drv_clear_tx_queue() ne détecte pas ce cas, car card_stop() vient de définir STOPPED ; la fonction poursuit l'exécution dans la boucle et déréférence un pointeur NULL. ResetAdapter() appelle bien init_smt(), mais uniquement après que les files ont été vidées.
La définition de l'adresse MAC sur une interface inactive provoque donc un plantage (oops) :
ip link set dev fddi0 address 02:00:00:00:00:01
BUG: KASAN: null-ptr-deref in mac_drv_clear_tx_queue+0x68/0x2c0 [skfp]
Read of size 8 at addr 0000000000000010 by task ip/302 Call Trace: <TASK> mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
netif_set_mac_address+0x1e4/0x2c0 do_setlink+0x684/0x2680 </TASK>
L'adresse 0x10 est le décalage de tx_curr_get, le troisième pointeur dans la structure s_smt_tx_queue, sur une architecture 64 bits. mac_drv_clear_rx_queue(), que ResetAdapter() appelle immédiatement après, déréférence smc->hw.fp.rx[QUEUE_R1] de la même manière derrière le même test hw_state inefficace ; c'est la file de transmission qui plante en premier. Les deux sont couverts par la garde ci-dessous.
Sauter la réinitialisation de l'adaptateur lorsque l'interface est inactive (down). dev_addr_set() reste inconditionnel, afin que la nouvelle adresse soit toujours enregistrée dans dev->dev_addr. Il n'y a aucune perte à ne pas réinitialiser l'adaptateur ici : skfp_open() relit délibérément l'adresse d'usine à chaque ouverture,
read_address(smc, NULL); eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a);
et le commentaire qui précède indique que cela est fait pour ignorer exactement une telle substitution d'adresse entre un cycle de fermeture/ouverture. Une adresse définie lorsque l'interface est inactive n'aurait pas survécu à l'ouverture suivante même avant cette modification, donc la garde ne supprime aucun comportement fonctionnel. Il s'agit d'une pratique établie que de protéger le côté matériel de ndo_set_mac_address() avec netif_running(); skge_set_mac_address() le fait depuis le commit 2eb3e621c4e0 ("skge: set mac address bonding fix").
Protéger la réinitialisation dans son ensemble, plutôt que d'effectuer un contrôle NULL sur les files, est également ce à quoi s'attend le reste du pilote. Après une ouverture/fermeture précédente, les pointeurs de file sont obsolètes mais non nuls, donc il n'y a pas de plantage, cependant ResetAdapter() continue d'appeler smt_online() et STI_FBI ("Enable Board Interrupts") alors que skfp_close() a déjà appelé free_irq() - l'adaptateur serait remis en ligne sans gestionnaire installé. L'autre appelant unique de ResetAdapter() est skfp_interrupt(), qui, par construction, ne s'exécute que lorsque le dispositif est ouvert.
Découvert lors d'une test automatisé du pilote contre un adaptateur FDDI SysKonnect émulé sous un noyau 7.0.0 avec KASAN activé. Son déclenchement nécessite CAP_NET_ADMIN.
VulDB is the best source for vulnerability data and more expert information about this specific topic.