Description

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:51.190Z",
  "pubdate": "2026-08-15T13:17:51.190Z",
  "executiveSummary": "An issue was discovered in the OpenvSwitch subsystem within the Linux kernel, specifically identified as ZDI-CAN-31642. The vulnerability is a Use-After-Free (UAF) flaw that occurs during meter attachment failures in the ovs_meter_cmd_set() function. When a newly created meter is prematurely exposed to other CPUs via attach_meter() before all initialization checks are finalized, a subsequent failure causes the code to detach and immediately free the meter structure using plain kfree() without respecting RCU grace periods.\nThis behavior violates Read-Copy Update synchronization protocols, as concurrent RCU readers may still hold references to the freed memory address. While standard management tools like ovs-vswitchd do not trigger this condition due to sequential creation constraints, an attacker utilizing a custom application via the Netlink uAPI can deliberately induce this race condition.\nSuccessful exploitation of this vulnerability leads to a kernel-level Use-After-Free condition, potentially resulting in local privilege escalation, denial of service through kernel panics, or arbitrary code execution depending on memory reuse patterns. The risk is constrained by the requirement to execute local operations or interact with the Netlink interface, though unprivileged or containerized contexts with network namespace access might present vectors depending on system configuration.",
  "technicalDetails": "The vulnerability resides in the OpenvSwitch kernel module, specifically within the meter management implementation located in net/openvswitch/meter.c. The affected components include the ovs_meter_cmd_set() function and the internal attach_meter() helper.\nThe root cause of the vulnerability is premature visibility combined with improper memory reclamation synchronization. During the execution of ovs_meter_cmd_set(), a new meter object is allocated and passed to attach_meter(). This function inserts the meter into visibility structures accessible by other CPU cores before all validation checks are fully completed. If an error occurs subsequently within the attachment or initialization path, the function unwinds and executes a plain kfree(meter) directly.\nBecause the meter was made visible to concurrent execution contexts, other cores may be executing ovs_meter_execute() within packet processing paths (via do_execute_actions() and ovs_execute_actions()), referencing the meter pointer via RCU read-side critical sections. Freeing the memory immediately via kfree() without invoking call_rcu() or synchronize_rcu() invalidates active references. Consequently, subsequent read operations on the freed memory address trigger a slab-use-after-free bug, as documented by KASAN reports in net/openvswitch/meter.c:653.\nThe attack flow proceeds as follows: 1) An attacker utilizes a custom application interacting with the Netlink uAPI to send crafted commands to the OpenvSwitch subsystem. 2) The application triggers an ovs_meter_cmd_set() request designed to pass initial allocation but fail during subsequent attachment phases. 3) The kernel prematurely exposes the meter to other CPUs. 4) The operation fails, causing the kernel to immediately deallocate the meter structure using kfree() while concurrent packet processing threads (RCU readers) are actively executing ovs_meter_execute() on the same memory block. 5) A Use-After-Free condition is triggered when RCU readers attempt to dereference the stale pointer.\nPrerequisites for triggering this condition include the ability to issue Netlink commands to the OpenvSwitch interface. Depending on the environment, this may require local execution privileges or access to a network namespace with OpenvSwitch configured."
}