CVE-2026-80994 in Linux
Résumé
par VulDB • 12/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: openvswitch : correction d'un use-after-free sur le masque de flux lors de sa suppression
Le commit indiqué dans la balise Fixes ci-dessous fait en sorte que la libération (free) du champ flow->mask soit planifiée via RCU juste après son retrait de la table des flux. Le pointeur reste présent dans la structure du flux et peut y être accessible au sein d'une même section critique RCU. Cette approche est adoptée afin d'éviter l'obligation d'utiliser ovs_mutex pour ovs_flow_free().
Cependant, lors de la suppression du flux pendant le traitement de CMD_DEL, nous n'acquérons pas le verrou de lecture RCU (RCU read lock) avant la suppression, et ovs_flow_cmd_fill_info() utilise ensuite le pointeur flow->mask. Le verrou de lecture RCU est acquis, mais trop tardivement à ce stade. Le commentaire sur cette ligne reconnaît que ce verrou est cosmétique et ne sert pas un objectif réel.
Cela entraîne un use-after-free si la période de grâce RCU s'écoule entre le retrait et le remplissage des informations. Il s'agit d'une fenêtre de course (race condition) courte, mais elle existe et peut provoquer un crash réel dans le cas où l'allocation de mémoire pour les informations prendrait un peu plus de temps :
BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Lecture de 4 octets à l'adresse ffff88801ee89970 par la tâche ovs_flow_del_ec/9487
Trace d'appel : <TASK> __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 </TASK>
Alloué par la tâche 9487 : mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556
Libéré par la tâche 9485 : rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062
ovs_flow_tbl_remove() doit être appelé après ovs_flow_cmd_fill_info() pour éviter cette condition de course. Cela aide également à nettoyer le cast forcé et le verrou de lecture RCU cosmétique. Avant le commit indiqué dans la balise Fixes, l'ordre n'avait pas d'importance tant que l'objet flux lui-même n'était pas libéré.
Une section critique RCU plus large pourrait être une autre option, mais nous sommes gênés par un allocation GFP_KERNEL.
Signalé par Zero Day Initiative de Trend Micro sous ZDI-CAN-32042.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.