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

net: openvswitch: fix middle attribute validation in pushnsh() action

The pushnsh() action structure looks like this:

OVSACTIONATTRPUSHNSH(OVSKEYATTRNSH(OVSNSHKEYATTRBASE,...))

The outermost OVSACTIONATTRPUSHNSH attribute is OK'ed by the nlaforeachnested() inside ovsnlacopyactions(). The innermost OVSNSHKEYATTRBASE/MD1/MD2 are OK'ed by the nlaforeachnested() inside nshkeyputfromnlattr(). But nothing checks if the attribute in the middle is OK. We don't even check that this attribute is the OVSKEYATTRNSH. We just do a double unwrap with a pair of nladata() calls - first time directly while calling validatepushnsh() and the second time as part of the nlaforeachnested() macro, which isn't safe, potentially causing invalid memory access if the size of this attribute is incorrect. The failure may not be noticed during validation due to larger netlink buffer, but cause trouble later during action execution where the buffer is allocated exactly to the size:

BUG: KASAN: slab-out-of-bounds in nshhdrfromnlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624

CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: <TASK> dumpstacklvl+0x51/0x70 printaddressdescription.constprop.0+0x2c/0x390 kasanreport+0xdd/0x110 kasancheckrange+0x35/0x1b0 asanmemcpy+0x20/0x60 nshhdrfromnlattr+0x1dd/0x6a0 [openvswitch] pushnsh+0x82/0x120 [openvswitch] doexecuteactions+0x1405/0x2840 [openvswitch] ovsexecuteactions+0xd5/0x3b0 [openvswitch] ovspacketcmdexecute+0x949/0xdb0 [openvswitch] genlfamilyrcvmsgdoit+0x1d6/0x2b0 genlfamilyrcvmsg+0x336/0x580 genlrcvmsg+0x9f/0x130 netlinkrcvskb+0x11f/0x370 genlrcv+0x24/0x40 netlinkunicast+0x73e/0xaa0 netlinksendmsg+0x744/0xbf0 syssendto+0x3d6/0x450 dosyscall64+0x79/0x2c0 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

Let's add some checks that the attribute is properly sized and it's the only one attribute inside the action. Technically, there is no real reason for OVSKEYATTRNSH to be there, as we know that we're pushing an NSH header already, it just creates extra nesting, but that's how uAPI works today. So, keeping as it is.

Hey Thomas,

Sorry for my delayed response. I see that these patches are now in the process of landing. Thank you so much for digging in on this and providing this context!

Best, - Kevin

On Fri, Jul 31, 2026 at 8:53 PM Thomas Ward <teward () ubuntu com> wrote: (Since my main mail and MS365 being the mail provider is, apparently, Not Okay here, I have to send from my alternate address... which ends up here anyways.)

Kevin,

The Ubuntu CVE website and tracker is a little fubar. This said, the CVE data is actually available in a separate git repository which has all the CVEs.

The CVE is listed as an Active CVE and there are no releases yet with the fix.

This does not mean that Ubuntu is ignoring it, but there are a very LARGE number of kernel variations across the current supported releases, each which needs patched, tested, etc.

A copy of the CVE tracker's behind-the-scenes data is available at https://paste.debian.net/hidden/2649d264 currently, copied to there by me. So this is in the Tracker, but the website part is broken.

This CVE was only made publicly available on 7/27 as well. The current test cycles are likely to take more than 4 days to get a release available because of testing all the variant kernel packages.

Thomas

On 2026-07-31 19:16, Kevin Riggle wrote:

Does anybody have any color as to why Ubuntu hasn't picked this up yet? Usually they're good about picking up the CVE even if they don't have a fix in place yet. If as is claimed in the report both 22.04 and 24.04 are vulnerable in default configuration out of the box, I would expect the CVE to be listed on https://ubuntu.com/security/ but it doesn't show up in search results and https://ubuntu.com/security/CVE-2026-64531 returns a 504 Gateway Timeout. Is there some disagreement as to the severity or exploitability of the vulnerability or are they just overloaded?

(Unrelatedly, the Ubuntu security site has been very flaky for me lately and even CVE pages that I know exist have been timing out on me. What's going on over there? Everybody who uses Ubuntu relies heavily on the Ubuntu security team, and I'm very worried about folks if we can't keep infrastructure up and we're likely burning people out.)

- Kevin

On Tue, Jul 28, 2026 at 6:06 AM manizada <manizada () pm me> wrote:

Hi folks,

Emailing here now that the embargo agreed upon with linux-distros@ has expired.

Flagging a local root vulnerability in the Linux kernel's Open vSwitch datapath (originally reported to security () kernel org and OVS maintainers on Jun 19). The fix is now public and has shipped in the relevant stable trees:

3f1f75536668 ("net: openvswitch: reject oversized nested action attrs")

The first fixed upstream stable releases are 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5.

Impact: Unprivileged user -> root code exec on affected systems where: - OVS kernel datapath and conntrack/FTP-helper support are present, and - unprivileged user/network namespaces are enabled, or the attacker otherwise has CAPNETADMIN over an attacker-controlled network namespace.

This affects many distros in stock config via unprivileged user namespaces. AppArmor/SELinux do not block the exploit once the attacker has the required CAPNETADMIN. Note that the nature of the bug makes it reachable from a container with an appropriate CAPNETADMIN, but I have not validated the container escape possibility.

Bug: Open vSwitch validates a userspace action list, then rewrites some actions into a larger internal swflowactions stream. The generated actions are stored as Netlink attributes, whose nlalen field is only 16 bits wide.

A March 2025 change removed the old 32 KiB cap on the total generated action stream, allowing the total stream to validly exceed 64 KiB, but exposing a pre-existing missing check on individual nested attributes.

An attacker can submit a valid action -- e.g., a CLONE -- containing hundreds of small conntrack actions. The kernel expands them until the generated CLONE exceeds 65,535 bytes, then stores that length in the 16-bit nlalen, causing it to wrap to a small value. Later dump/free consumers trust the wrapped length and resume parsing from inside the generated conntrack data.

Conntrack labels and timeout names are attacker-controlled, so fake OUTPUT and SET actions can be planted exactly where parsing resumes. The PoC turns those fake actions into a kernel pointer leak, a kernel-memory read, and a targeted decrement primitive, then corrupts a host process's credentials and writes a sudoers rule for root code execution.

Affected distros: Below is a summary of the tested distros. The full table, including cases where available vendor kernels are unaffected or stock policy blocks exploitation, is in the attachment (and in an easier-to-read format in the writeup linked below).

Stock-default exploitable distros (an affected regular-track kernel is installed + OVS/conntrack support is present + unprivileged namespaces are permitted by default):

- AlmaLinux 9.7 Workstation/Azure cloud, 9.8, 10.1 Workstation/Azure cloud, and 10.2 x86-64/x86-64-v2 - Alpine Linux 3.22.4/3.23.4/3.24.1 Cloud and 3.22.5/3.23.5/3.24.1 LTS/virt - Amazon Linux 2023 KVM (6.1/6.12/6.18 kernel tracks) - Arch Linux monthly (linux/linux-lts/linux-zen) - CentOS Stream 9 Cinnamon/GNOME/KDE/MATE/XFCE and 10 GNOME/KDE - Debian 12/13 - Fedora 40 Workstation/Server after an ordinary same-track update (the stock ISO kernel is unaffected) - Fedora 41 Workstation/Server after an ordinary same-track update (the stock ISO kernel is unaffected) - Fedora 42/43/44 Workstation/Server - Gentoo amd64 cloud image and stable gentoo-kernel-bin 6.1/6.6/6.12/6.18 branches - Kali Linux 2026.1 - Linux Mint 22.3 Cinnamon - NixOS 24.11/25.05/25.11/26.05 - openSUSE Tumbleweed GNOME/KDE - Pop!OS 22.04 Intel/24.04 Generic - Rocky Linux 9/10 KDE/Workstation/Workstation Lite - Ubuntu 22.04 Desktop minimal/full and Server - Ubuntu 24.04 Desktop minimal/full and Server

Exploitable after the listed non-default change, with no other default config changes: - Arch Linux monthly linux-hardened (set kernel.unprivilegedusernsclone=1, disabling the hardening) - Linux Mint 21.3 Cinnamon (install the optional linux-generic-hwe-22.04 kernel track) - Oracle Linux 8/9/10 KVM (install and load the missing OVS/conntrack module packages) - Ubuntu 26.04 Desktop minimal/full, Server, and generic/AWS/Azure/GCP/GKE/Oracle cloud kernel tracks (set kernel.apparmorrestrictunprivilegeduserns=0)

Immediate-term mitigations (aside from backporting the kernel fix): - Unloading the openvswitch module and blocking it from loading if OVS is not required (assuming it is not built into the kernel) - Disabling unprivileged user namespaces (though this does not block the potential container-escape path described above) - Using the emergency BPF mitigation included with the PoC if OVS and unprivileged namespaces must remain available.

The issue is tracked under CVE-2026-64531.

Full writeup: https://heyitsas.im/posts/ovswrap

PoC for validation; BPF mitigation: https://github.com/manizada/OVSwrap

Thanks, -Asim Manizada -- Kevin Riggle - Principal, Complex Systems Group LLC he/him • Brooklyn, NY, USA • Eastern Time https://complexsystems.group • https://calendly.com/kevinriggle/coffee