DirtyDecrypt: PoC Released for yet another Linux flaw

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.

In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.

PackageKit is a a D-Bus abstraction layer that allows the user to manage packages in a secure way using a cross-distro, cross-architecture API. PackageKit between and including versions 1.0.2 and 1.3.4 is vulnerable to a time-of-check time-of-use (TOCTOU) race condition on transaction flags that allows unprivileged users to install packages as root and thus leads to a local privilege escalation. This is patched in version 1.3.5. A local unprivileged user can install arbitrary RPM packages as root, including executing RPM scriptlets, without authentication. The vulnerability is a TOCTOU race condition on `transaction->cached_transaction_flags` combined with a silent state-machine guard that discards illegal backward transitions while leaving corrupted flags in place. Three bugs exist in `src/pk-transaction.c`: 1. Unconditional flag overwrite (line 4036): `InstallFiles()` writes caller-supplied flags to `transaction->cached_transaction_flags` without checking whether the transaction has already been authorized/started. A second call blindly overwrites the flags even while the transaction is RUNNING. 2. Silent state-transition rejection (lines 873–882): `pk_transaction_set_state()` silently discards backward state transitions (e.g. `RUNNING` → `WAITING_FOR_AUTH`) but the flag overwrite at step 1 already happened. The transaction continues running with corrupted flags. 3. Late flag read at execution time (lines 2273–2277): The scheduler's idle callback reads cached_transaction_flags at dispatch time, not at authorization time. If flags were overwritten between authorization and execution, the backend sees the attacker's flags.

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.

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.

In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.

In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.