Linux bitten by second severe vulnerability in as many weeks
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-43284 | Linux kernel ESP-in-UDP decrypts in place over shared splice pages (CWE-123) CVE-2026-43284 is a write-what-where memory-safety flaw (CWE-123) in the Linux kernel's xfrm/ESP (IPsec) code: the IPv4/IPv6 UDP datagram send paths fail to mark pages spliced into a UDP skb with SKBFL_SHARED_FRAG when MSG_SPLICE_PAGES attaches pipe pages, so the ESP input path wrongly treats the packet as privately owned and decrypts it in place over memory the skb does not exclusively own. It is triggered when locally generated UDP traffic built from spliced pipe pages is processed by the ESP decryption path, typically in IPsec NAT-traversal (ESP-in-UDP, UDP port 4500) configurations; the in-place decrypt can corrupt or expose data still referenced by the pipe or other owners of those shared pages. A local, low-privileged attacker can thereby cause high-severity confidentiality, integrity, and availability impact that extends beyond the packet itself (CVSS 3.1: 8.8, scope changed); no remote or unauthenticated trigger is described. Any Linux system running a kernel with the vulnerable UDP splice and ESP-in-UDP paths is affected, most importantly IPsec VPN gateways and clients; the advisory lists no affected version ranges. No public proof-of-concept or confirmed in-the-wild exploitation is known (not on CISA KEV), but EPSS assigns a 93.2% probability of exploitation within 30 days (100th percentile), so patching should not be deferred. Do: Apply your distribution's kernel security update containing the xfrm/esp fix for CVE-2026-43284 and reboot into the patched kernel, prioritizing IPsec VPN gateways and clients that use ESP-in-UDP NAT-T (UDP/4500). Until patched, restrict untrusted local users from sending splice-based (MSG_SPLICE_PAGES) UDP traffic through IPsec-protected paths, or temporarily avoid ESP-in-UDP encapsulation where feasible. Verify the fix via your vendor's package changelog, as the advisory does not name specific fixed version numbers. | 8.8 | 93% |
| mass≈1M+ Linux installations carry the vulnerable code in default distro kernels; hundreds of thousands of hosts expose IPsec NAT-T (UDP/4500) in public internet… | ||
| CVE-2026-43500 | Out-of-bounds write in Linux kernel AF_RXRPC decryption enables root access CVE-2026-43500 is a memory-corruption flaw in the Linux kernel's AF_RXRPC (rxrpc) subsystem: the DATA and RESPONSE packet handlers only copy received skbs to a linear buffer before decryption when the skb is marked cloned, so non-cloned skbs that still carry externally owned paged fragments (SKBFL_SHARED_FRAG, e.g. set by splice() into a UDP socket, or skbs with a frag_list) fall through to the in-place decryption path. In that path the shared fragment pages are bound directly into the AEAD/skcipher scatter-gather list via skb_to_sgvec(), so decryption writes into pages shared with other kernel or user contexts, causing out-of-bounds/write-what-where corruption (CWE-787/CWE-123), notably via the splice-into-UDP-socket loopback vector. A local low-privileged attacker who can get the machine to process such rxrpc packets can corrupt kernel memory and escalate to root (CVSS 3.1: 7.8 high, local vector, high confidentiality/integrity/availability impact). Affected systems are Linux kernels with the AF_RXRPC subsystem available — the transport used by the AFS/kAFS network filesystem — which mainstream distribution kernels ship as a module or built-in; no specific affected or fixed version ranges are provided in the data. It is not on CISA's KEV list and the CVE record lists no public PoC, but news reports describe a 'Dirty Frag' local privilege-escalation exploit giving root across major distributions and a released PoC, and EPSS puts the 30-day exploitation probability at about 93% (100th percentile). Do: Apply the kernel update containing the rxrpc fix as soon as your distribution ships it — the fix extends the unshare gate to also unshare skbs with frag lists or shared fragments before in-place decryption; no fixed version numbers are given in the available data, so follow your distro's security advisory. Until patched, check whether rxrpc/AFS is in use (e.g. 'lsmod | grep rxrpc') and avoid or restrict local splice()-into-UDP/loopback AFS traffic on multi-user hosts. | 7.8 | 93% |
| mass≈1 billion+ Linux installations (mainstream distro kernels ship AF_RXRPC) |
Full article503 words · extracted from arstechnica.com · click to collapse
Both privilege escalation vulnerabilities stem from bugs in the kernel’s handling of page caches stored in memory, allowing untrusted users to modify them. They target caches in networking and memory-fragment handling components. Specifically, CVE-2026-43284 attacks the esp4 and esp6 () processes, and CVE-2026-43500 zeroes in on rxrpc. Last week’s CopyFail exploited faulty page caching in the authencesn AEAD template process, which is used for IPsec extended sequence numbers. A 2022 vulnerability named Dirty Pipe also stemmed from flaws that allow attackers to overwrite page caches.
Researchers from security firm Automox wrote:
Dirty Frag belongs to the same bug family as Dirty Pipe and Copy Fail, but it targets the frag member of the kernel’s struct sk_buff rather than pipe_buffer. The exploit uses splice() to plant a reference to a read-only page-cache page (for example, /etc/passwd or /usr/bin/su) into the frag slot of a sender-side skb. Receiver-side kernel code then performs in-place cryptographic operations on that frag, modifying the page cache in RAM. Every subsequent read of the file sees the corrupted version, even though the attacker only ever had read access.
CVE-2026-43284 is found in the esp_input() process on the IPsec ESP receive path. When an skb object is non-linear but lacks a frag list, the code skips skb_cow_data() and decrypts AEAD in place on the planted frag. From there, an attacker can control the file offset and the 4-byte value of each store.
CVE-2026-43500, meanwhile, resides in rxkad_verify_packet_1(). The process decrypts RxRPC payloads using a single-block process. Splice-pinned pages become both a source and destination. That, paired with the decryption key being freely extracted using the add_key (rxrpc), allows an attacker to rewrite contents in memory.
Either exploit used separately is unreliable. Some Ubuntu configurations use AppArmor to prevent untrusted users from creating namespace contents. That, in turn, neutralizes the ESP technique. Most other distributions by default don’t run rxrpc.ko, which neutralizes the RxRPC arm. When chained together, however, the two exploits allow attackers to obtain root on every major distribution Kim tested. Once the exploits run, attackers can use SSH access, web-shell execution, or container escapes, or compromise low-privilege accounts.
“Dirty Frag is notable because it introduces multiple kernel attack paths involving rxrpc and esp/xfrm networking components to improve exploitation reliability,” Microsoft researchers wrote. “Rather than relying on narrow timing windows or unstable corruption conditions often associated with Linux local privilege escalation exploits, Dirty Frag appears designed to increase consistency across vulnerable environments.”
Researchers at Google-owned Wiz said exploits will be less likely to break out of hardened containerized environments like Kubernetes with default security settings in place. “However, the risk remains significant for virtual machines or less restricted environments.”
The best response for anyone using Linux is to install patches immediately. While fixes likely require a reboot, protection from a threat as severe as Dirty Frag outweighs the cost of disruptions. Anyone who can’t install immediately should follow the mitigation steps laid out in the posts linked above. Additional guidance can be found here.
Text extracted automatically; images, tables and formatting may be missing. Original: https://arstechnica.com/security/2026/05/linux-bitten-by-second-severe-vulnerability-in-as-many-weeks/