CVE-2026-98797 in Linux
Résumé
par VulDB • 19/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: limiter skb->queue_mapping lorsque la file d'attente de transmission (tx queue) est sélectionnée
skbedit peut définir skb->queue_mapping et activer l'indicateur skip_txqueue par CPU afin que __dev_queue_xmit() respecte le mappage. __dev_queue_xmit() effaçait cet indicateur avant sch_handle_egress() et ne le lisait qu'après, de sorte que l'indicatrice n'était pas confinée à la transmission (xmit) qui l'avait activé : une transmission imbriquée (redirection mirred ou mirror, ou un drop après skbedit) pouvait activer l'indicateur, et la transmission externe le consommerait pour un skb qui n'est jamais passé par skbedit.
Un paquet transféré conserve toujours rx_queue + 1 de la NIC d'entrée dans skb->queue_mapping ; l'appareil externe indexe alors son état de file d'attente tx avec cette valeur obsolète. Le tableau enfant q->qdiscs[] de Taprio est dimensionné selon le nombre de files d'attente de l'appareil, donc taprio_enqueue() effectue un indexage au-delà de son allocation et déréférence le résultat en tant que struct Qdisc *.
Nous (ab)usons de skb->nf_skip_egress qui signifie « ignorer netfilter egress pour ce paquet » afin d'indiquer « suis-je dans tc egress ? ». Malgré cette surcharge, je ne vois pas cela comme un conflit car le marqueur n'est défini que autour de l'appel unique à sch_handle_egress() et la voie d'entrée est protégée par tc_at_ingress. J'enverrai un correctif de suivi (net-next) une fois celui-ci intégré dans net-next pour renommer le bit/indicateur skb->nf_skip_egress en skb->skip_egress.
Armer l'indicateur uniquement depuis la classeuse egress capable de l'utiliser : activer skip_txqueue à partir de tcf_skbedit_act() uniquement lorsqu'il s'exécute dans sch_handle_egress(), grâce à skb->nf_skip_egress. Une classeuse qdisc d'egress s'exécute dans q->enqueue(), après que la file tx a été sélectionnée, donc un mappage qu'elle définit ne peut pas affecter le paquet actuel ; armer l'indicateur là n'en pollue que pour une transmission ultérieure. Prenez ensuite possession de l'indicateur pour la frame xmit dans laquelle s'exécute le hook egress : sauvegardez la valeur entrante et effacez-la juste avant sch_handle_egress(), puis restaurez-la après le hook - sur la voie consommée (drop), ou, dans le même appel qui le lit, sur la voie survivante. La sauvegarde et les restaurations restent à l'intérieur de la branche statique egress_needed_key, donc un paquet ne paie pour elles que lorsque les hooks d'egress sont actifs (2f1e85b1aee4).
Stockez la valeur sélectionnée par netdev_cap_txqueue() dans skb->queue_mapping via netdev_tx_queue_mapping(), comme le fait déjà netdev_core_pick_tx(), afin que la voie skip_txqueue ne remette jamais à un lecteur ultérieur sur la voie xmit un mappage que l'appareil ne peut pas servir. Un stockage effectué plus tardivement dans la même frame, par un programme tc BPF attaché à une qdisc de transmission, est en dehors de cette voie et n'est pas re-limité ; un correctif de suivi séparé résoudra cette voie.
netdev_xmit_skip_txqueue() renvoie la valeur précédente de l'indicateur afin que la sauvegarde-et-effacement soit un seul appel, et une stub no-op est fournie lorsque CONFIG_NET_EGRESS est désactivé. skb->nf_skip_egress est compilé sous CONFIG_NET_EGRESS plutôt que CONFIG_NETFILTER_SKIP_EGRESS, donc skb_at_tc_egress() est valide chaque fois que la voie egress est construite.
Un utilisateur local dans un namespace réseau peut rediriger un paquet d'un appareil avec plus de files TX vers un autre avec moins après avoir défini un mappage valable uniquement sur le plus grand appareil. Cela atteint ces lectures et, sous KASAN, provoque une faute avec « slab-out-of-bounds in taprio_enqueue ».
Conditions pour recréer le bug : le déclencheur du rapport est un utilisateur local disposant de CAP_NET_ADMIN dans un namespace réseau, donc aucun programme eBPF n'est nécessaire. Avec CONFIG_NET_SCH_TAPRIO=y, CONFIG_NET_ACT_SKBEDIT=y, CONFIG_NET_ACT_MIRRED=y, CONFIG_NET_CLS_MATCHALL=y, CONFIG_NET_SCH_PRIO=y et KASAN activé, créez qa (3 files), qb (2 files) et qc (1 file) en tant qu'appareils dummy ; placez une racine taprio sur qb (num_tc 1, queues 2@0) et clsact sur les trois ; puis ajoutez un filtre matchall egress sur chaque appareil. Sur qa : « action skbedit queue_mapping 2 pipe action mirred egress redirect dev qb ». Sur qb : « action mirred egress mirror dev qc ». Sur qc : « action skbedit queue_mapping 0 pipe ». Envoyez un paquet depuis qa. Le skbedit de qc active l'indicateur tandis que la transmission externe de qb est en cours ; sans le correctif, qb le consomme et lit son tableau enfant taprio à deux entrées avec le mappage obsolète du paquet transféré. Un qc dont le skb ---tronqué---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.