ZeroHour
Help Net Securitypublished ()ingested @zeljkazorz

Linux developers weigh emergency "killswitch" for vulnerable kernel functions

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2026-31431
Local Privilege Escalation (Copy Fail) in Linux Kernel algif_aead Interface

CVE-2026-31431 ('Copy Fail') is an incorrect resource transfer between spheres (CWE-669/CWE-1288) in the Linux kernel's algif_aead implementation of the AF_ALG userspace crypto interface, introduced roughly nine years ago (around 2017, per public reporting) when commit 72548b093ee3 switched AEAD operations to in-place handling even though the source and destination buffers come from different mappings. A local, unprivileged user can trigger the flaw by performing AEAD operations through the AF_ALG socket interface, causing the kernel to mishandle the copy of ciphertext and associated data. Successful exploitation provides a reliable local privilege escalation to root (C:H/I:H/A:H per the CVSS vector). Nearly every major Linux distribution and enterprise platform is exposed, including the kernel itself, Red Hat Enterprise Linux (including AUS, EUS, TUS and Update Services for SAP Solutions), OpenShift Container Platform, Amazon Linux, Ubuntu, Debian, openSUSE Leap, SUSE CaaS Platform, NixOS, and Linux-based products from Arista and Siemens. The flaw has public proof-of-concept code, a 99.9% EPSS score, and was added to CISA's Known Exploited Vulnerabilities catalog on 2026-05-01, indicating exploitation in the wild (ransomware use is unknown).

Do: Patch by installing the kernel update for CVE-2026-31431 through your distribution's security channel (Red Hat Enterprise Linux including AUS/EUS/TUS/SAP channels, OpenShift, Amazon Linux, Ubuntu, Debian, openSUSE Leap, SUSE CaaS Platform, NixOS, and Arista/Siemens firmware/software as applicable) and reboot into the patched kernel; the data provides no fixed version numbers, so defer to vendor advisories. Because the flaw is in CISA's KEV catalog (added 2026-05-01) with a 99.9% EPSS score, prioritize internet-reachable and multi-user systems first and follow BOD 22-01 guidance for cloud services. Check running kernel versions ('uname -r') and distribution advisory status to confirm you are on a fixed build.

7.8100% KEV PoC ×5
  • Linux kernel (algif_aead / AF_ALG crypto interface)
  • Red Hat Enterprise Linux (including AUS, EUS, TUS, and Update Services for SAP Solutions)
  • Red Hat OpenShift Container Platform
  • +8 more
masshundreds of millions to billions of installations (servers, cloud instances, desktops, and Android/embedded devices running affected kernel generations)
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.893%
  • Linux kernel
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.893%
  • Linux kernel
mass≈1 billion+ Linux installations (mainstream distro kernels ship AF_RXRPC)
Full article573 words · extracted from helpnetsecurity.com · click to collapse

Linux kernel developers are reviewing a proposal for an emergency risk mitigation mechanism (“Killswitch”) that would allow administrators to disable vulnerable kernel functions at runtime.

The proposal, submitted by Linux kernel developer/maintainer Sasha Levin, arrives in the wake of the public disclosure of two privilege escalation vulnerabilities affecting the Linux kernel.

What prompted the proposal

The impetus for the proposal is explicit: the patch’s selftest references Copy Fail (CVE-2026-31431), a nine-year-old local privilege escalation flaw in the AF_ALG cryptographic socket interface disclosed by researchers at Theori on April 29.

The flaw allows an unprivileged local user to write four controlled bytes into the kernel page cache of any readable file, reliably achieving root without needing to win a race condition.

Copy Fail’s disclosure process was chaotic: Linux kernel developers were notified in advance and had time to work on a fix, but various Linux distributions were still working on issuing patched kernel packages when Theori researchers published a working proof-of-concept exploit.

Dirty Frag was publicly disclosed on May 7 by researcher Hyunwoo Kim, who privately reported CVE-2026-43284 and CVE-2026-43500, which together “make” Dirty Frag, to kernel maintainers on April 29–30.

But when a patch for CVE-2026-43284 got merged on May 5, it didn’t take long for another researcher to analyze it, create a working exploit, and publish it, forcing Kim to proceed with public disclosure before the agreed-upon embargo window ended.

(The researcher in question didn’t know about the embargo. “The work is n-day weaponization from a public upstream commit, which is standard practice once a security-relevant fix lands in a public tree,” he noted.)

Copy Fail demonstrated that due to a poor understanding of the intricacies of the process, even well-intentioned disclosure can leave distros scrambling. Dirty Frag demonstrated how vulnerability disclosure embargos are futile if a fix lands in a public repository.

The Killswitch

The killswitch proposal is an acknowledgment of the fact that if the window between disclosure and patched packages cannot be reliably controlled, Linux administrators need a way to reduce their exposure on their own terms.

“When a (security) issue goes public, [Linux] fleets stay exposed until a patched kernel is built, distributed, and rebooted into,” Levin explained.

For many vulnerabilities, including Copy Fail and Dirty Frag, administrators can reduce their exposure immediately by blacklisting the affected kernel module or unloading it if already running (though this may break specific functionality).

But that approach only works for code that lives in loadable modules. Some vulnerable code paths are compiled directly into the kernel and can’t be unloaded. That’s why Killswitch is meant to work at the function level, regardless of where that vulnerable code lives.

“Killswitch lets a privileged operator [i.e., admin] make a chosen kernel function return a fixed value without executing its body,” Levin explained, and pointed out that the mitigation is immediate and lasts until the next reboot.

Killswitch can reduce exposure during the window between public disclosure and the availability of patched kernel packages, but it’s good to note that it’s meant as a stop-gap measure until a fix can be implemented.

Nevertheless, it may be just what many admins (and especially those administrating large computer fleets) are looking for.

The patch is currently being reviewed and re-worked, and it remains to be seen if it will be added to the kernel.

Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

Text extracted automatically; images, tables and formatting may be missing. Original: https://www.helpnetsecurity.com/2026/05/11/linux-kernel-emergency-killswitch/