CVE-2026-46300 Fragnesia: Linux Kernel Bug Exposed on GKE Since May

On May 13, 2026, CVE-2026-46300, dubbed Fragnesia, emerged as a local privilege escalation vulnerability in the Linux kernel that allows an unprivileged user to obtain root privileges by corrupting the page cache of privileged binaries. The flaw specifically affects the XFRM ESP-in-TCP subsystem and represents a variant of the DirtyFrag family, with a public proof-of-concept available and an upstream patch released on May 24, 2026 in Linux v7.1-rc5. The impact is greatest in multi-tenant cloud environments such as Google Kubernetes Engine, where unprivileged user namespaces are enabled by default.

The Mechanism: A Lost Flag in an Optimization Function

The Linux kernel uses zero-copy networking where the page cache of files can be referenced directly as paged frags inside socket buffers (skb). The SKBFL_SHARED_FRAG flag marks these frags as shared with an external page cache. When skb_try_coalesce() transfers frags between skbs, it fails to propagate this flag. Subsequently, ESP input (IPsec) checks skb_has_shared_frag() to decide whether to perform copy-on-write (COW) before in-place decryption; without the flag, ESP writes directly into the shared page cache.

The result is a recurring arbitrary-write primitive: an attacker can corrupt the page cache of already-loaded privileged binaries, altering their behavior without touching the file on disk. This bypasses hash-based file integrity checks and leaves minimal traces for post-incident forensic analysis.

How Escalation Is Achieved: CAP_NET_ADMIN via Namespace

The exploit requires the CAP_NET_ADMIN capability, normally reserved for root. However, on Debian and Fedora with default settings, this capability is obtainable through unprivileged user namespaces. A container or process in an unprivileged user namespace can thus configure the IPsec stack and trigger the vulnerable ESP-in-TCP path.

The variant is particularly insidious because it requires no race condition: the public PoC works deterministically. According to Tenable Research, the original DirtyFrag patches do not fix Fragnesia, making a specific kernel update necessary.

"The underlying problem isn’t a single buggy helper function. It’s a contract problem: every code path that moves skb fragments must preserve the shared-frag bit, every time." — JFrog Security Research, via The Hacker News

Timeline and Patch Availability

Fragnesia was disclosed on May 13, 2026. The upstream patch was merged into Linux v7.1-rc5 on May 24, 2026, with a commit that explicitly propagates SKBFL_SHARED_FRAG in skb_try_coalesce(). Siemens subsequently released the fix in firmware V3.1.6, as documented in advisory SSA-019113. B&R Industrial Automation confirmed impact on products using Linux for B&R version 12 or earlier.

No confirmation of active in-the-wild exploitation has emerged in the dossier at the time of publication. However, the combination of a public PoC, absence of a race condition, and bypass of previous patches constitutes a high-risk profile for environments not yet updated.

What to Do Now

Update the kernel to the version that includes the commit for skb_try_coalesce(), identified in Linux v7.1-rc5 and subsequent vendor backports.

Verify firmware versions on Siemens and B&R devices: Siemens firmware V3.1.6 fixes CVE-2026-46300; for B&R, Linux for B&R updated beyond version 12 is required.

Evaluate disabling unprivileged user namespaces where the operational impact on containers and CI/CD pipelines is manageable, given that this capability is the prerequisite for exploitation on default Debian/Fedora configurations.

Monitor the page cache for anomalous writes to privileged in-memory binaries, with specific attention to processes configuring XFRM/ESP in unprivileged namespace contexts.

Why the DirtyFrag Pattern Won’t Stop at Point Patches

Fragnesia fits into a family of vulnerabilities — DirtyFrag — that exploit the same attack surface: page cache manipulation via networking write primitives. Every fix that intercepts a single code path leaves the door open for variants that find other helpers dropping the shared-frag contract. The JFrog Security Research quote underscores this: the problem is structural, not isolated.

For cloud infrastructure operators, this means risk management requires not just reactive patching but also a review of isolation architecture. GKE and multi-tenant container environments where unprivileged user namespaces are enabled by default present a systemic attack surface that point patches do not fully mitigate.

FAQ

Does Fragnesia require physical access to the machine?

No. It is a local vulnerability that requires user access to the system, but not physical access. In containerized or cloud environments, a user with a shell in a pod or container can trigger the exploit.

Why don’t the original DirtyFrag patches protect against this?

The DirtyFrag patches intercepted other code paths that manipulated paged frags. Fragnesia specifically exploits skb_try_coalesce(), which was not included in the original shared-frag contract review.

Has Google confirmed GKE is vulnerable?

The dossier does not contain a specific GKE advisory for CVE-2026-46300. The GKE context is inferred from the combination of: Linux kernel and containerd use in GKE, enablement of unprivileged user namespaces in default configurations, and description of multi-tenant container impact in analysis sources. The primary cloud.google.com source does not mention this specific CVE.

Sources

• https://docs.cloud.google.com/kubernetes-engine/security-bulletins
• https://www.tenable.com/cve/CVE-2026-46300
• https://cert-portal.siemens.com/productcert/html/ssa-019113.html
• https://www.cisa.gov/news-events/ics-advisories/icsa-26-174-06
• https://securelist.com/vulnerabilities-and-exploits-in-q2-2026/121091/
• https://www.securityweek.com/dirtyclone-linux-kernel-vulnerability-leads-to-root-access/
• https://thehackernews.com/2026/06/new-dirtyclone-linux-kernel-flaw-lets.html

Information verified against cited sources and current as of publication.

Fonti