Answer in brief
CVE-2026-74465 records a Unknown severity vulnerability in net: openvswitch: fix potential UAF on meter attach failure. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <0310d1fa7f9debd0d89629e9f14c7975a47eaa9a || >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <4d03e5fa3fbb1df15258a1eb3d6963f0d65659b3 || >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <90623c9499627803ef3f04fa25a3199402d4fb95 || >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <431a295d93f76fbdb6a7cfce92a9e3dfee1e5d61 || >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <a58a2b0ce354df531ebc71fc870058c2feb59f6b | 0310d1fa7f9debd0d89629e9f14c7975a47eaa9a, 4d03e5fa3fbb1df15258a1eb3d6963f0d65659b3, 90623c9499627803ef3f04fa25a3199402d4fb95, 431a295d93f76fbdb6a7cfce92a9e3dfee1e5d61, a58a2b0ce354df531ebc71fc870058c2feb59f6b |
| Linux/Linuxgeneric | 5.8 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-74465 records a Unknown severity vulnerability in net: openvswitch: fix potential UAF on meter attach failure. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <0310d1fa7f9debd0d89629e9f14c7975a47eaa9a || >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <4d03e5fa3fbb1df15258a1eb3d6963f0d65659b3 || >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <90623c9499627803ef3f04fa25a3199402d4fb95 || >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <431a295d93f76fbdb6a7cfce92a9e3dfee1e5d61 || >=c7c4c44c9a95d87e50ced38f7480e779cb472174 <a58a2b0ce354df531ebc71fc870058c2feb59f6b | 0310d1fa7f9debd0d89629e9f14c7975a47eaa9a, 4d03e5fa3fbb1df15258a1eb3d6963f0d65659b3, 90623c9499627803ef3f04fa25a3199402d4fb95, 431a295d93f76fbdb6a7cfce92a9e3dfee1e5d61, a58a2b0ce354df531ebc71fc870058c2feb59f6b |
| Linux/Linuxgeneric | 5.8 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.