CISA Flags Three Actively Exploited Linux Kernel Flaws, Orders Federal Patch by Sunday

CISA is adding three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog Friday, giving federal civilian agencies until Sunday, September 21 — just 72 hours — to apply fixes or accepted mitigations under the terms of Binding Operational Directive 26-04. All three carry confirmed evidence of active exploitation in the wild. The trio spans three unrelated kernel subsystems — the kernel-level TLS receive path, the bridge netfilter ebtables module, and the cryptographic user API — a combination that signals CISA treats the threat as broad rather than narrow.

The severity of the three-day deadline is not routine. Under BOD 26-04, issued June 10, 2026 , only vulnerabilities that score highest on all four risk factors — publicly internet-exposed asset, confirmed exploitation, automatable exploit, full-system-compromise potential — land in the directive's most aggressive remediation tier. All three of Friday's additions meet that bar. The same backdrop makes the deadline harder: the 2026 Verizon Data Breach Investigations Report found that only 26% of KEV vulnerabilities were fully remediated in 2025, down from 38% the year before, with median time to full remediation stretching to 43 days.

What Is kTLS, and Why Is the TLS Receive Flaw the Most Severe of the Three

CVE-2025-39682 affects net/tls/tls_sw.c , the Linux kernel's software implementation of TLS record processing on the receive side. When an application configures a TCP socket with TCP_ULP set to "tls" , the kernel takes ownership of decrypting incoming TLS records — a feature known as kernel TLS (kTLS) — and delivers plaintext directly to the application, bypassing userspace libraries such as OpenSSL. The optimization is widely used on high-throughput Linux servers: content delivery networks, reverse proxies, and database servers frequently enable kTLS to accelerate TLS termination.

The flaw lives in tls_sw_recvmsg() . The function is designed to process either a sequence of contiguous TLS data records or a single non-data record (such as an alert or handshake message) per call — not both in one pass. The corner case that was missed: when the initial record pulled from the rx_list queue is zero-length, the type-change detection logic can be bypassed entirely. In TLS 1.3, where the actual record type is not known until after decryption, a subsequent record of a different type can then be processed under the wrong assumptions. In zero-copy mode (when darg.zc == 1 ), the kernel queues the anchor socket buffer ( strp->anchor ) into rx_list — a forbidden operation in that mode. This corrupts the anchor's reference count, producing a use-after-free when the socket is closed and tls_sw_release_resources_rx walks the freed memory.

Researchers at Singapore-based STAR Labs discovered the vulnerability; the firm's publicly available proof-of-concept , which triggers a KASAN-confirmed UAF at kfree_skb_list_reason , is confirmed circulating. CVSS 3.1 scores this flaw at 7.1 High, with local attack vector, low privilege required, and no user interaction needed. Red Hat has issued patches for Red Hat Enterprise Linux 9 ( kernel-0:5.14.0-570.49.1.el9_6 ) and RHEL 10 under advisories RHSA-2025:16880 and RHSA-2025:16904 .

How the ebtables Flaw Corrupts Kernel Memory Through an ARP Packet

CVE-2026-53266, published June 25, 2026, resides in the bridge netfilter subsystem — specifically the ebt_snat target, which allows ebtables rules to rewrite the source MAC address in bridged Ethernet frames. The vulnerability is a missing writability check before a memory write operation.

When the ebt_snat target processes an ARP packet, it uses skb_header_pointer() to safely read the ARP header. But a subsequent call to skb_store_bits() is used to overwrite the sender MAC address at an offset into skb->data . The problem: skb_header_pointer() provides read-only access and does not guarantee that the target memory region is writable. When the ARP sender hardware address range is held in a nonlinear socket buffer fragment backed by a splice-imported file page, the write proceeds directly into that backing page without the kernel verifying it has write access. The result is an out-of-bounds write capable of corrupting kernel memory belonging to entirely unrelated objects. Local privilege escalation via kernel memory corruption is the documented impact.

An attacker exploiting this flaw typically needs the ability to load netfilter rules — usually requiring CAP_NET_ADMIN or equivalent privilege. Red Hat issued fixes under Red Hat advisory RHSA-2026:36645 , RHSA-2026:39082, and RHSA-2026:39083.

What Can Go Wrong When Two Threads Write to the Same Crypto Socket

CVE-2025-39964 affects the AF_ALG interface — the kernel subsystem that exposes cryptographic operations to userspace applications through socket-like file descriptors, published October 13, 2025. The vulnerability is a race condition: the AF_ALG data path permitted two concurrent writers on the same socket simultaneously. Request payloads from separate threads can interleave unpredictably inside the kernel's cryptographic processing queue, leaving the per-socket context inconsistent.

The practical outcomes range from corrupted cryptographic output — which is dangerous on its own for any system relying on kernel-mediated crypto — to a kernel panic and denial of service. A deliberate attacker can construct two threads writing to the same AF_ALG socket in a tightly timed loop. Scoring this flaw is contested: the NVD assigns a CVSS base score of 3.3 Low; Red Hat rates it 5.5 Medium; the CVE Naming Authority at cve.org assigns 7.8 High. Administrators should use the CISA KEV listing as the authoritative signal that active exploitation is confirmed regardless of CVSS score. Red Hat's CVE-2025-39964 security page documents the full scoring dispute.

What BOD 26-04 Changes the Federal Patch Clock

The 72-hour deadline is a direct consequence of Binding Operational Directive 26-04, which CISA issued June 10, 2026, under the formal title "Prioritizing Security Updates Based on Risk." The directive replaced two long-standing predecessors — BOD 22-01 (2021) and BOD 19-02 (2019) — and fundamentally changed how Federal Civilian Executive Branch (FCEB) agencies are expected to respond.

The model assigned flat remediation deadlines based solely on CVSS severity, treating every KEV entry the same regardless of exposure context. BOD 26-04 replaces that with a four-variable risk model that evaluates: whether the asset is publicly internet-exposed; whether the vulnerability appears in the KEV catalog; whether exploitation is automatable; and what the potential technical impact is. Vulnerabilities that score highest on all four variables land in the most aggressive remediation tier: three calendar days, with an additional forensic triage requirement mandating that agencies determine whether the asset was already compromised before the patch was applied.

All three Friday additions fall into this tier. The September 21 deadline applies to FCEB agencies; federal contractors who support or operate covered systems must enable agency compliance under their contract terms. The CIQ compliance analysis provides additional context on what the three-day window means for federal Linux teams.

How the 26% Remediation Problem Makes Every 72-Hour Clock Harder

BOD 26-04 sets an aggressive deadline against a documented industry failure. The same Verizon report CISA cites as evidence that AI is compressing the window between vulnerability disclosure and weaponization also documents that only 26% of KEV vulnerabilities were fully remediated in 2025 — down from 38% the prior year — and that the median time to full remediation stretched to 43 days, up from 32. Even the best-performing organizations manage to close only 30–40% of KEV instances within the first week after detection. The number of KEV vulnerabilities organizations had to address in 2025 was 50% higher than the year before, compounding the capacity ceiling.

The implication is not that administrators should ignore the deadline but that most organizations are statistically operating with insufficient remediation throughput to meet it without dedicated prioritization effort. Risk-based patching — treating Friday's three kernel additions as displacing other scheduled work — is exactly the behavior BOD 26-04 is designed to enforce, but doing so requires visibility into kernel versions deployed across every Linux system in an environment. Organizations running periodic rather than continuous asset inventory will face the greatest gap.

What Comes in a Kernel Patch That Doesn't Come in a Configuration Change

A critical distinction for administrators: all three fixes require a kernel update followed by a system reboot. There is no configuration-only workaround for CVE-2025-39682 that eliminates the vulnerability without disabling kTLS entirely; the fix is a code change in tls_sw_recvmsg() that correctly handles the zero-length record corner case. Similarly, CVE-2026-53266's fix requires the upstream patch to ebt_snat to add the skb_ensure_writable() call before the ARP SHA write; disabling ebtables SNAT rules is a workaround that may not be operationally feasible. For CVE-2025-39964, Red Hat's guidance lists a module-level mitigation (preventing af_alg from loading via blacklist), but this disables all kernel-mediated cryptography for applications that rely on it. Red Hat's CVE-2025-39964 mitigation page details the blacklist procedure.

Live-patching solutions — kpatch for Red Hat environments , Canonical Livepatch for Ubuntu — can apply kernel security fixes without a reboot in many cases and are particularly relevant for critical infrastructure that cannot schedule downtime on a 72-hour window. Whether they cover Friday's specific CVEs depends on the vendor's live-patch release schedule; administrators should check their vendor's live-patch catalog before assuming reboots can be deferred.

What Administrators Should Do Before Sunday

These steps apply regardless of whether an environment is a federal agency:

Identify kernel versions in use. CVE-2025-39682 affects Linux kernel 6.0 through 6.16.3 and release candidates 6.17-rc1 and 6.17-rc2; CVE-2025-39964 affects kernel 2.6.38 through multiple branches up through 6.16.9 and 6.17-rc6, making it a much older and broader exposure surface than its low NVD CVSS score suggests. Apply vendor-supplied kernel updates for your distribution.

Check kTLS exposure. Servers using kernel TLS offload (identifiable via setsockopt(SOL_TLS) usage or per-application configuration) should be treated as highest priority among CVE-2025-39682 targets, particularly those running in multi-tenant environments where a compromised user process could reach the kernel through this path. CISA's KEV guidance notes that even patched hosts that were previously exposed should undergo forensic triage to determine whether exploitation preceded the fix.

Audit ebtables rules. If your environment uses bridge ebtables with SNAT rules for ARP rewriting — common in some containerized and virtualized network configurations — apply vendor kernel patches immediately and restrict CAP_NET_ADMIN access to trusted processes only.

Restrict AF_ALG access as an interim measure. If patching cannot happen immediately, consider preventing the af_alg module from loading, though this may affect applications relying on kernel-mediated cryptography.

Plan reboots now. All three fixes require a kernel update and reboot unless a verified live-patch is available for your distribution and version. Build the maintenance window into Friday's planning, not Sunday morning.

Additional Linux Kernel Privilege Escalation Flaws Disclosed This Week

Friday's KEV additions coincide with separate disclosures this week of four additional Linux kernel local privilege escalation vulnerabilities — dubbed DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121), and DiagSpill (CVE-2026-74469) — by security researcher Asim Manizada. Those four have not been added to the KEV catalog, indicating CISA has not yet confirmed active exploitation, but their disclosure in the same week as Friday's additions reflects sustained attacker interest in the Linux kernel's networking and cryptographic subsystems.

The kTLS receive path in particular has seen multiple researchers probe its logic over the past year, with the zero-copy optimization path frequently implicated. The combination of kernel-level memory access, direct TLS record handling, and the complexity of TLS 1.3's post-decryption type disambiguation makes net/tls/tls_sw.c an area security researchers and threat actors continue to scrutinize closely.

Frequently Asked Questions

Does the 72-hour BOD 26-04 deadline apply to private companies, or only federal agencies?

BOD 26-04 is a binding requirement only for Federal Civilian Executive Branch agencies and the contractors who operate covered systems on their behalf. For private-sector organizations, CISA's guidance is advisory — but the practical urgency is identical: CISA adds vulnerabilities to the KEV catalog only when there is confirmed real-world exploitation. Three simultaneously confirmed-exploited kernel flaws, including one with a public proof-of-concept, carry operational risk that does not respect organizational category. The 2026 Verizon DBIR recorded only 26% full remediation of KEV vulnerabilities industry-wide in 2025; using CISA's KEV listing as a de facto private-sector priority list is precisely the use CISA recommends.

How do I know whether my servers are using kernel TLS (kTLS) for CVE-2025-39682?

Kernel TLS is enabled at the application level, not the kernel level — a kernel can support it without any application activating it. On Linux, the kernel TLS ULP is loaded when an application calls setsockopt(SOL_TCP, TCP_ULP, "tls") on a connected socket. Common software that uses kTLS includes nginx (with ssl_protocols TLSv1.3 and the kTLS engine configured), some versions of OpenSSL with the ktls provider, and custom high-performance server software. Running ss -npt | grep tls or checking your webserver configuration for kTLS engine references will help identify exposed services. Any internet-facing server in a multi-tenant environment — hosting providers, CDN edge nodes, database servers — should treat this as highest priority among the three CVEs.

What is the significance of CISA requiring forensic triage alongside the patch — not just patching?

BOD 26-04 adds a requirement that agencies determine whether a system was already compromised before the patch arrived. This is new compared to the old BOD 22-01 model, which treated patching as the end state. For CVE-2025-39682 specifically, because a public proof-of-concept has been circulating since September 2025, systems running vulnerable kernel versions may have been exposed to exploitation attempts for up to a year before Friday's KEV addition. Forensic triage means reviewing kernel crash logs, KASAN output, and audit logs for signs of privilege escalation during that window — not just applying the patch and moving on.

Will patching from 26% of KEV remediations be enough — or is CISA's three-day clock structurally unrealistic?

The 2026 Verizon DBIR data shows the first-week remediation rate across organizations has remained between 30% and 40% for three years despite additional tooling and mandate pressure. BOD 26-04's three-day deadline sits well inside that window. CISA designed the directive knowing the existing remediation ceiling — the goal is not to achieve 100% compliance but to ensure the highest-risk exposures are treated as operational emergencies that displace other work, not queue items that wait for the patch cycle. For Friday's three kernel CVEs, that means treating the September 21 deadline as a planning constraint, not an aspirational goal.