CVE-2026-80994

In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: fix flow mask use-after-free on flow deletion

The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs mutex for the ovs flow free().

However, while removing the flow during processing of CMD DEL, we do not take RCU read lock before the removal, and ovs flow cmd fill info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose.

This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer:

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 Read of size 4 at addr ffff88801ee89970 by task ovs flow del ec/9487

Call Trace: 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

Allocated by task 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

Freed by task 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() must be called after the ovs flow cmd fill info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed.

A wider RCU critical section could be another option, but we have a GFP KERNEL allocation in the way.

Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.