Three CVEs, One Deadline, and a Bug That Waited Thirteen Years: This Week's Linux Kernel Headlines

On 18 September 2026, CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog in one go. All three are confirmed under active exploitation. All three carry a Binding Operational Directive 26-04 remediation deadline of 21 September, which is Monday — a two-day window that only gets handed out when an agency has real evidence attackers are already using something, not a hypothetical. Red Hat’s own advisory language for one of them is about as blunt as vendor copy gets: “This CVE is high risk and there are known public exploits leveraging this vulnerability.”

That’s three. There’s a fourth kernel bug doing the rounds this week that hasn’t made CISA’s list yet, and arguably should worry you more: a thirteen-year-old logic flaw in the kernel’s Open vSwitch code that a single upstream change quietly turned into a full local-root exploit, complete with a public proof-of-concept that already has prebuilt offsets for around 800 different kernel builds. Here’s what all four actually do.

The three CISA just mandated

CVE-2025-39682 — kTLS receive path

Red Hat’s own description is the clearest one going: “a logic bug in the kTLS receive path mishandles zero-length records taken from the rx_list, allowing a mixed record-type sequence to slip past the per-recvmsg() type constraint and proceed to data processing.” In plain terms, kernel TLS’s zero-copy decrypt path gets confused when the first queued record it looks at happens to be zero-length, and a carefully sequenced set of records can use that confusion to reach code paths a normal record sequence never would.

This is the one CVE of the three where I’d flag the scoring itself as worth a second look before you lean on the number alone. Red Hat rates it 7.0 (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H), Oracle’s tracker shows the same 7.0 with an identical local-access vector, and at least one independent research tracker lands at 7.1 with a similar local-attack-vector read. At least one aggregator has it listed as 9.8, which doesn’t match any vector string I could actually find behind that number. Every source that publishes a full CVSS vector agrees on AV:L — this needs a local presence on the box, not a bare network connection — even though the practical severity once you have that presence is real: high confidentiality, integrity, and availability impact across the vectors that do check out.

CVE-2026-53266 — ebtables SNAT/ARP rewrite path, CVSS 8.8

This one lives in ebtables’ Source NAT target, specifically its optional feature for rewriting the ARP sender hardware address as a packet passes through: an out-of-bounds write from insufficient bounds checking before that rewrite happens. CVSS 8.8, vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — local access, low complexity, low privilege needed to start, and a scope change, meaning the damage isn’t contained to the vulnerable component itself. That combination is why this one reads as a genuine local-privilege-escalation primitive rather than just a crash. ebtables sits underneath a lot of container and bridge networking setups that never get a second look once they’re working, which is exactly the kind of code path that stays exploitable for a long time once someone finds the bug.

CVE-2025-39964 — AF_ALG socket race condition

The third is a race condition in AF_ALG — the kernel’s socket-based interface to its own crypto API — that surfaces when two processes write to the same AF_ALG socket concurrently. The data gets interleaved unpredictably and the socket’s internal state ends up inconsistent. Scoring here varies more than I’d like across trackers: Wiz’s database shows 5.5 with an availability-only vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H — crash, nothing else), while other aggregators list it as high as 7.8. The underlying behaviour every source agrees on is a local attacker crashing the system, not reading or altering data they shouldn’t; treat the higher numbers you’ll see quoted elsewhere with that in mind.

None of the three write-ups I could find gave a named threat actor, a campaign, or a public proof-of-concept for any of the three — just the flat CISA/Red Hat confirmation that exploitation is happening. That’s consistent with how KEV entries usually surface: confirmation first, technical detail later, if it ever gets published at all. Worth noting too that all three need local access to trigger, which narrows who should be most worried: shared hosts, containers running on a kernel you don’t fully trust, and any multi-tenant box where “local” doesn’t mean “trusted.” If that’s your environment, the practical response is the same regardless of which of the three is closer to your actual exposure: patch to a kernel that includes all three fixes, don’t wait to see which CVSS number is the “real” one.

The one not on the list: CVE-2026-64531, OVSwrap

This is the one that’s been circulating under the name OVSwrap, and it’s a genuinely interesting bug on top of being a dangerous one. The root cause has been sitting in the kernel’s Open vSwitch datapath for thirteen years: OVS stores the list of flow actions a userspace program submits as Netlink attributes, and the length field on those attributes is 16 bits wide. Nobody could hit the overflow in practice, because a 32 KiB cap on the total size of a generated action stream kept any single set of actions well clear of the 65,535-byte boundary where a 16-bit field wraps around.

That cap was removed in an upstream change in March 2025, for reasons that had nothing to do with security. It just made a dormant bug reachable. Submit a CLONE action containing enough conntrack sub-actions and the generated nested action attribute now exceeds 65,535 bytes, the 16-bit length field wraps, and OVS’s parser resumes reading at an offset the attacker chose. From there the public exploit chains three primitives: a kernel pointer leak through a fake OUTPUT action, an arbitrary kernel read through a forged tunnel SET action, and a targeted decrement via a tun_dst pointer teardown. Put together, that’s local root.

What makes this worse than the usual “needs elevated access” caveat is what “local access” means here. The attack needs OVS’s conntrack support and the FTP conntrack helper loaded, and CAP_NET_ADMIN — which any unprivileged user can hand themselves inside an unprivileged user namespace with a plain unshare -Urn. No sudo, no existing foothold beyond an ordinary shell. And Open vSwitch ships as part of the default kernel module set on most enterprise and community Linux distributions whether or not anyone on the box has ever configured software-defined networking: AlmaLinux 9 and 10, Alpine 3.22 through 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 and 10, Debian 12 and 13, Fedora 42 through 44, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 and 10, and Ubuntu 22.04 through 26.04 are all named as affected in default configuration. That’s most of the Linux estate anyone reading this actually runs, homelab or otherwise.

The upstream fix shipped in stable trees on 24 July 2026: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5 all carry it. If you’re tracking one of the end-of-life series in between — 6.13 through 6.17, 6.19, or 7.0 — there is no upstream fix coming and moving to a maintained series is the only real answer. Where you can’t patch immediately, the two workarounds that don’t require a reboot are blocking the module from loading at all (echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf) or disabling unprivileged user namespaces system-wide, both of which cost you real functionality if you actually use OVS or namespace-based sandboxing, so treat them as a bridge to the real patch rather than a destination.

What to actually do this week

• Check your running kernel version against the fixed builds above for OVSwrap, and separately confirm your distro’s latest kernel update includes the three CISA-listed CVEs — vendor backport numbering doesn’t always match upstream version numbers directly, so check the changelog, not just the version string.
• If you’re a federal agency or contractor under BOD 26-04, the three KEV entries have a hard deadline of 21 September. Everyone else should still treat that date as the target, because “known public exploits” doesn’t become less true once the directive stops applying to you.
• If a patched kernel isn’t available yet for OVSwrap on your platform, apply one of the two workarounds above now and track your vendor’s advisory for the real fix — don’t sit on unpatched exposure with CAP_NET_ADMIN as the only barrier between an ordinary user and root.
• Don’t assume “no PoC published” means “not exploited,” and don’t assume “PoC published” means every environment running the affected code is equally exposed. Treat both as reasons to patch, on different timelines.

Four bugs, two very different stories: three that CISA has already confirmed are being used against real systems today, and one that sat quietly correct-by-accident for thirteen years until an unrelated change turned it into the kind of bug that gets its own name. Patch for both kinds.