Look up another CVE · open CVE-2026-74465 in the interactive tracker
CVE-2026-74465
net: openvswitch: fix potential UAF on meter attach failure
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem net/openvswitch. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-74465 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the "hash" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/openvswitch/meter.c
- What this is
- OPENVSWITCHMAINTAINERS section matched on net/openvswitch/ · netdev@vger.kernel.org · Maintained
- Kernel module
- openvswitch
Check it on the machine
grep -w CONFIG_OPENVSWITCH /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w openvswitchPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_OPENVSWITCH
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.15%, higher than 4.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/openvswitch
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.8 | 5.10.265 | 496f3013c6ff |
| 5.8 | 5.15.216 | ddc0ef4217cc |
| 5.8 | 6.1.183 | b0de3b58dac3 |
| 5.8 | 6.6.151 | 0310d1fa7f9d |
| 5.8 | 6.12.103 | 4d03e5fa3fbb |
| 5.8 | 6.18.44 | 90623c949962 |
| 5.8 | 7.1.8 | 431a295d93f7 |
| 5.8 | 7.2 | a58a2b0ce354 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The UAF is triggered when ovs_meter_cmd_set() fails attach_meter() and kfree()s the meter without an RCU grace period; that path is only reachable via the ovs_meter genetlink uAPI (netlink_sendmsg), not by remote packet reception alone.
- AC:LAttack complexity, low
- The attacker controls both sides of the race by concurrently issuing OVS_METER_CMD_SET (forcing post-insert attach failure at max_meters or ENOMEM) and OVS_PACKET_CMD_EXECUTE or traffic on flows with OVS_ACTION_ATTR_METER while parallel_ops allows overlapping handlers.
- PR:LPrivileges required, low
- OVS_METER_CMD_SET and OVS_PACKET_CMD_EXECUTE require CAP_NET_ADMIN checked with netlink_ns_capable() against the socket network namespace; unprivileged users can obtain CAP_NET_ADMIN in a user namespace (unshare -Urn) and the genl family is netnsok.
- UI:NUser interaction, none
- Exploitation requires only programmatic netlink API calls from the attacker; no victim user action such as opening files, mounting filesystems, or clicking prompts is needed.
- S:UScope, unchanged
- Successful exploitation compromises kernel memory and privileges on the same host/kernel security authority; it does not inherently cross a VM hypervisor, IOMMU, or hardware isolation boundary.
- C:HConfidentiality impact, high
- This is a slab use-after-free: concurrent ovs_meter_execute() reads freed dp_meter fields (bands, stats, lock) via RCU lookup, enabling heap spraying and arbitrary kernel memory disclosure primitives.
- I:HIntegrity impact, high
- The UAF write path updates freed meter and band statistics, bucket counters, and takes a spinlock on freed memory, providing memory corruption primitives that can be developed into arbitrary kernel writes or code execution.
- A:HAvailability impact, high
- KASAN reproduces slab-use-after-free in ovs_meter_execute during concurrent meter attach failure; UAF on the datapath fast path can cause kernel oops/panic or be abused for repeatable denial of service.