CVE-2026-80994: net: openvswitch: fix flow mask use-after-free on flow deletion
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 ovsmutex for the ovsflowfree().
However, while removing the flow during processing of CMDDEL, we do not take RCU read lock before the removal, and ovsflowcmdfillinfo() 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 ovsnlaputkey net/openvswitch/flownetlink.c:1996 BUG: KASAN: slab-use-after-free in ovsnlaputkey+0x2463/0x2e30 net/openvswitch/flownetlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovsflowdelec/9487
Call Trace: <TASK> ovsnlaputkey net/openvswitch/flownetlink.c:1996 ovsnlaputkey+0x2463/0x2e30 net/openvswitch/flownetlink.c:2250 ovsflowcmdfillinfo+0x420/0x9c0 net/openvswitch/datapath.c:930 ovsflowcmddel+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlinkrcvskb+0x156/0x420 net/netlink/afnetlink.c:2556 </TASK>
Allocated by task 9487: maskalloc net/openvswitch/flowtable.c:967 flowmaskinsert net/openvswitch/flowtable.c:1012 ovsflowtblinsert+0xea2/0x1a90 net/openvswitch/flowtable.c:1084 ovsflowcmdnew+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlinkrcvskb+0x156/0x420 net/netlink/afnetlink.c:2556
Freed by task 9485: rcufreesheaf+0x1e/0x100 mm/slub.c:5978 rcudobatch kernel/rcu/tree.c:2645 rcucore+0x59c/0x10c0 kernel/rcu/tree.c:2897 handlesoftirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1062
ovsflowtblremove() must be called after the ovsflowcmdfillinfo() 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 GFPKERNEL allocation in the way.
Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
net/openvswitchto a version that resolves this vulnerability.Patch ZDI-CAN-32042
Event History
Frequently Asked Questions
What activity is required to trigger the race?
The race occurs while processing a CMD_DEL request that removes an Open vSwitch flow. The flow’s mask can be freed after removal and then accessed while generating flow information if an RCU grace period passes in between.
What impact has been observed when the race is hit?
The reported outcome is a kernel slab use-after-free that can cause a real crash. KASAN reports identify the read in __ovs_nla_put_key in net/openvswitch/flow_netlink.c, reached through ovs_nla_put_key.
How can I look for evidence that a system is affected?
Review kernel logs and KASAN output for “slab-use-after-free in __ovs_nla_put_key” and call traces involving ovs_nla_put_key and net/openvswitch/flow_netlink.c. The issue is timing-dependent and is described as having a short race window.