Kernel Security on KnightLi Blog

CVE-2026-43494 / PinTheft: Local Privilege Escalation Risk from Linux RDS and io_uring

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 is a Linux kernel local privilege escalation risk. The related exploitation chain is also known publicly as PinTheft. The key point is not a remote entry point, but whether a low-privilege local user can line up RDS zerocopy, io_uring fixed buffers, a readable SUID-root program, and a suitable kernel version.

One naming detail is worth clarifying first: the Unclecheng-li/poc-lab repository directory is named CVE-2026-43494 PinTheft, while the README title also mentions QVD-2026-27616 - PinTheft. Based on public CVE entries and third-party advisories, CVE-2026-43494 points to a Linux kernel RDS zerocopy issue where op_nents is not reset correctly, leading to a double-free / reference-counting anomaly. QVD-2026-27616 appears more like a Qianxin risk advisory identifier. In real triage, record both identifiers, but treat distribution security advisories and kernel patch status as the source of truth.

What Is the Core Bug?

The issue appears in the zerocopy send path of Linux RDS, Reliable Datagram Sockets. Public descriptions point to these key functions:

1
2

rds_message_zcopy_from_user()
rds_message_purge()

When iov_iter_get_pages2() fails inside rds_message_zcopy_from_user(), pages that have already been pinned can be released by the error path, but the related op_nents state is not cleared correctly. Later, rds_message_purge() may still release the residual entries again. The result is that the same batch of page references can be decremented too many times, creating an exploitable reference-counting error.

Viewed alone, the RDS bug is an error-path memory-management issue inside the kernel. PinTheft becomes dangerous because the exploitation chain connects it with the io_uring fixed-buffer mechanism: io_uring still keeps an old struct page *, while the page itself has already been freed and reallocated for another purpose. The public PoC then steers this state toward overwriting the page cache of a SUID-root program, eventually reaching local privilege escalation.

Why It Is Called PinTheft

io_uring REGISTER_BUFFERS pins user pages. For normal pages, FOLL_PIN is not just a simple reference increment; it raises the page refcount through a larger bias. The public PoC uses the concept of GUP_PIN_COUNTING_BIAS = 1024.

The name PinTheft means the attack chain repeatedly “steals” those pin references through the RDS zerocopy failure path. After the references are drained, io_uring still believes it holds a valid page, but that physical page can now be freed and reused by the page cache.

This class of vulnerability is easy to misread as “directly modifying /usr/bin/su on disk.” A more accurate description is that the exploitation chain tries to overwrite the in-memory page cache. The file itself may not be written back to disk, but when the kernel executes the SUID program, it may fetch instructions from the contaminated page cache and run the attack payload.

The Trigger Conditions Are Not Broad

This is not a vulnerability where “any Linux server can be remotely hit.” Public information indicates that the exploitation chain depends on at least these conditions:

The kernel has CONFIG_RDS and CONFIG_RDS_TCP enabled.
The system has CONFIG_IO_URING enabled, and kernel.io_uring_disabled=0.
The rds / rds_tcp modules are already loaded, or a low-privilege user can trigger autoloading.
A readable SUID-root binary exists locally, such as /usr/bin/su, /usr/bin/passwd, or /usr/bin/pkexec.
The public PoC also depends on the newer IORING_REGISTER_CLONE_BUFFERS API. CloudLinux analysis notes that the public PoC is more aligned with kernel 6.13 and later.

If any one of these links is missing, the public exploitation path breaks. For example, many RHEL-family distributions do not compile RDS by default, older Ubuntu kernels may lack the io_uring clone-buffer API needed by the PoC, and some environments restrict automatic RDS module loading by unprivileged users.

One-Minute Self-Check

First, check the kernel configuration:

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

Then check whether io_uring is disabled:

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

Interpret the common values like this:

0: allowed, giving the largest exposure.
1: restricted for unprivileged users; exact behavior depends on kernel version and distribution policy.
2: io_uring disabled.

Check whether the RDS modules exist and can be loaded:

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

If CONFIG_RDS is not set, or the system has no rds_tcp module at all, this bug usually cannot be reached. Conversely, if RDS is available, io_uring is not disabled, and the system uses a relatively new general-purpose kernel, continue checking distribution fix status with higher priority.

Which Machines Deserve Priority

Prioritize these environments:

Multi-user Linux hosts, teaching machines, jump hosts, and shared development machines.
Container hosts, especially environments that allow untrusted local users or have a loose container escape surface.
Desktops or servers running newer mainline / rolling kernels, such as Arch-like rolling distributions.
HPC, Oracle RAC, or other scenarios that may genuinely use RDS.
CI workers, build machines, and lab environments that allow unprivileged users to run large amounts of local code.

For an ordinary web server where only controlled service accounts run applications and RDS is not enabled, the practical risk is much lower. But “much lower” does not mean “ignore it”: the typical impact of a kernel local privilege escalation is that an attacker first gains low-privilege access through Web, SSH, CI, containers, or an application bug, then uses the local bug to expand control.

Temporary Mitigation Ideas

The proper fix should still come from the distribution kernel update. Patch status, backported versions, and affected ranges must be checked against advisories from Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, Arch, cloud vendors, or container base-image providers. Do not judge only by the upstream version number.

While waiting for patches, or when an immediate kernel reboot is not possible, choose temporary measures according to the environment:

# If the business does not depend on RDS, block related module loading
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

If the business does not depend on io_uring, consider disabling or restricting it:

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

Persistent configuration needs to be written into the appropriate /etc/sysctl.d/*.conf file. Be careful with this step: modern databases, proxies, runtimes, or high-performance I/O programs may use io_uring. Confirm business dependencies before changing production systems.

How to Verify After Fixing

After upgrading the kernel, do not rely only on package-manager success output. Confirm three things:

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

If a distribution advisory explicitly says CVE-2026-43494 is fixed, the kernel may still be protected even when uname -r does not look like the newest upstream release, because the stable distribution kernel may have received a backported patch. Conversely, if the kernel comes from a self-built tree, third-party repository, cloud marketplace image, or container host template, continue checking the patch commit and build time.

References

Impact Summary of Four Recent Linux Local Security Issues: Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

Several high-profile local security issues have appeared in the Linux ecosystem recently. Individually, they involve different areas: crypto interfaces, network and IPsec paths, page cache handling, and ptrace access checks. Together, they point to the same operational lesson: once an attacker has a low-privilege local execution point, the risk to Linux hosts, container nodes, CI machines, and multi-user servers increases sharply.

This article does not repeat all technical details of each vulnerability. Instead, it summarizes their practical impact and links to four separate articles on this site for deeper reading.

What the Four Events Affect

The four risks worth tracking are:

Copy Fail (CVE-2026-31431): a low-privilege local user may affect the page cache through kernel crypto-related paths and expand privileges.
Dirty Frag (related to CVE-2026-43284 / CVE-2026-43500): risk centers on xfrm/ESP, RxRPC, and related network and kernel data paths, making it dangerous in post-compromise scenarios.
Fragnesia (CVE-2026-46300): close to Dirty Frag, involving XFRM ESP-in-TCP, shared fragments, and page-cache write risk.
ssh-keysign-pwn (CVE-2026-46333): not a direct root-shell bug, but a local information disclosure risk that may expose SSH host private keys, /etc/shadow, and other sensitive files.

The entry points differ, and so do the mitigations. Fixing Copy Fail does not automatically cover Dirty Frag or Fragnesia. Disabling some network modules does not automatically remove the information disclosure risk around ssh-keysign-pwn.

Copy Fail: High Priority for Containers and CI Nodes

The key impact of Copy Fail is not an application crash. It is that low-privilege execution may be turned into root privileges. It is especially sensitive in these environments:

CI/CD nodes that allow users to upload or run code.
Container hosts running untrusted workloads.
Development machines, jump hosts, and shared servers.
Cloud hosts running older kernels with slower patch cycles.

The danger is that Copy Fail has a relatively low exploitation threshold and combines easily with container scenarios. Many teams treat containers as a strong isolation boundary, but ordinary containers still share the host kernel by default. If an attacker gets a shell inside a container, a kernel LPE can turn a container issue into a host issue.

Detailed analysis: Copy Fail CVE-2026-31431: Container Escape Risk in a Linux Kernel File-Copy Path.

Dirty Frag: A Post-Compromise Amplifier

Dirty Frag is more like a privilege amplifier after an attacker has entered a system. It is not a typical remote unauthenticated vulnerability. The usual prerequisite is that the attacker already has local execution through a weak password, WebShell, low-privilege service account, container task, or another foothold.

Its practical impact appears in several places:

A compromised low-privilege account may become root.
A low-privilege execution point inside a container may threaten the host.
Systems using IPsec, ESP, RxRPC, or related kernel networking capabilities need careful patch and mitigation review.
Security teams should look beyond perimeter defense and include post-compromise privilege escalation chains.

Dirty Frag reminds operations teams that local privilege escalation may not be the first entry point, but it can decide how far an intrusion goes. Once a low-privilege foothold exists, attackers will look for kernel bugs to push privileges to the highest level.

Detailed analysis: Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide.

Fragnesia: Similar Attack Surfaces Are Not Cleaned Up All at Once

Fragnesia matters because it shows that the attack surface near Dirty Frag is not an isolated one-off issue. Even if one bug is fixed, neighboring paths, similar data structures, and related module combinations may still contain new exploitable points.

Its operational impact is mainly:

Do not handle only the vulnerability name once. Keep checking by attack surface.
esp4, esp6, rxrpc, XFRM, and ESP-in-TCP should be evaluated against actual business dependencies.
If a system does not depend on the related network capabilities, temporary disabling may be considered, but it must be tested first to avoid breaking VPN, IPsec, tunnels, or internal networking.
Page-cache pollution risks can create detection blind spots where files appear unchanged, but the execution path is affected.

For enterprises, the biggest lesson is that patch management should not look only at a single CVE. A safer approach is to build an inventory around subsystems and attack surfaces, then identify which machines expose the relevant capabilities and which services truly need those modules.

Detailed analysis: Fragnesia (CVE-2026-46300): Linux Kernel Local Privilege Escalation Impact and Mitigation.

ssh-keysign-pwn: Not Direct Root, Still Dangerous

ssh-keysign-pwn differs from the previous three. It is more of a local sensitive information disclosure issue than a direct root-shell vulnerability. But in real attacks, sensitive information disclosure can quickly become a larger incident.

The main impacts include:

Leaked SSH host private keys may damage host identity trust.
Access to files such as /etc/shadow can lead to offline cracking and account takeover.
Multi-user servers, jump hosts, build machines, and shared development machines carry higher risk.
Even without immediate privilege escalation, attackers may obtain credential material useful for lateral movement.

This type of issue is easy to underestimate because it does not look as dramatic as a direct root shell. In enterprise environments, however, key and password-hash exposure often means a longer cleanup cycle: rotating SSH host keys, reviewing trust relationships, checking account passwords, and auditing login logs.

Detailed analysis: ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk.

Shared Impact: Containers Are Not a Strong Boundary by Default

Taken together, these four events make one point clear: ordinary container isolation is not virtual-machine isolation.

Docker, containerd, and Kubernetes use namespaces, cgroups, capabilities, seccomp, AppArmor, and SELinux to reduce attack surface, but they usually still share the host kernel. If the vulnerability is in the shared kernel, a low-privilege execution point inside a container can become an entry point.

High-risk environments should check:

Whether untrusted code is allowed to run on shared hosts.
Whether containers run as root by default.
Whether unnecessary capabilities are granted.
Whether seccomp policies are too broad.
Whether multi-tenant workloads should move to gVisor, Kata Containers, Firecracker microVM, dedicated virtual machines, or dedicated nodes.

CI/CD platforms deserve special attention. Build jobs naturally run external code, dependency install scripts, test scripts, and temporary binaries. If these jobs share hosts with long-running services, one local privilege escalation can affect much larger infrastructure.

Shared Impact: Patches Must Reach the Running Kernel

A common Linux kernel patching mistake is assuming that an installed package means the machine is running the fixed kernel.

At minimum, operations teams should verify three things:

`1`	`uname -a`

Check the currently running kernel.

`1`	`dpkg -l \| grep linux-image`

Or on RHEL-family distributions:

`1`	`rpm -qa \| grep kernel`

Check installed kernel packages.

Finally, confirm that the machine has rebooted into the fixed kernel. For core services that cannot reboot immediately, evaluate livepatch, hot patching, or short-term isolation, but do not treat temporary mitigation as the final fix.

Shared Impact: Attack Surface Reduction Must Be Specific

These vulnerabilities remind us that Linux hardening cannot stop at “update the system” and “enable a firewall.”

More specific checks include:

Whether AF_ALG / algif_aead is used by business workloads.
Whether XFRM, ESP, ESP-in-TCP, and IPsec are required by VPNs, tunnels, or security gateways.
Whether RxRPC is needed.
Whether unprivileged user namespaces must be enabled.
Whether containers can create overly broad socket types.
Whether ptrace access policies are too loose.

If the business does not need certain capabilities, evaluate disabling modules, adjusting sysctl settings, tightening seccomp, and reducing capabilities. Do not blindly copy commands into production. Inventory dependencies first, then roll out changes gradually.

Suggested Response Order

First, prioritize machines where local code execution is exposed:

Container hosts.
CI/CD runners.
Jump hosts.
Multi-user servers.
Hosts running external-facing services.
Systems running untrusted plugins, scripts, or extensions.

Second, confirm distribution advisories and the actual running kernel. Do not rely only on upstream version numbers. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, openEuler, and other distributions may backport security fixes.

Third, tighten container runtime policies. Prefer non-root users, minimal capabilities, no-new-privileges, read-only filesystems, and explicit seccomp plus AppArmor or SELinux policies.

Fourth, review key and credential exposure. Especially for environments affected by ssh-keysign-pwn, evaluate whether SSH host keys, /etc/shadow, jump-host credentials, and CI secrets need rotation.

Fifth, improve monitoring. Watch for abnormal root shells, suspicious local LPE PoCs, critical file changes, abnormal ptrace behavior, container processes accessing host paths, and unusual network connections from CI nodes.

Conclusion

The point of these four events is not “Linux is insecure.” The point is that default trust is no longer enough.

Linux remains transparent, fixable, configurable, and hardenable. But in environments where containers, CI, multi-tenancy, and AI-driven code execution are increasingly common, a low-privilege execution point can no longer be treated as a minor issue. If the kernel contains exploitable local privilege escalation or sensitive information disclosure bugs, a partial intrusion can become host control, credential exposure, or lateral movement.

A more realistic approach is to treat these four events as a reminder: patch quickly, confirm rebooted kernels, enable modules only when needed, tighten containers, make key rotation possible, and reassess isolation levels for multi-tenant workloads.

ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn refers to a set of exploitation paths around a logic flaw in Linux kernel __ptrace_may_access(), assigned CVE-2026-46333. It is not a remote unauthenticated flaw and it does not directly hand out a root shell, but the risk is still high: a low-privileged local user may read root-owned sensitive files that should be inaccessible, such as SSH host private keys or /etc/shadow.

For operations teams, the priority is not reproducing a PoC. The priority is to identify affected machines, upgrade the kernel, reboot into the fixed kernel, and rotate SSH host keys or reset passwords when necessary.

Bottom line

This vulnerability deserves high handling priority for four reasons:

It can be triggered by a low-privileged local user and does not require root.
Public PoC code is available, lowering the exploitation barrier.
The potential targets are not ordinary files, but SSH host private keys and /etc/shadow.
The fix requires a kernel patch and reboot; installing packages without rebooting is not enough.

If your servers have multiple users, local shell access, shared hosting, CI runners, container hosts, student lab machines, bastion hosts, or any local users you do not fully trust, handle this first.

What the vulnerability is

Qualys disclosed details on oss-security on May 15, 2026. They had previously reported a Linux kernel __ptrace_may_access() logic issue to security@kernel.org, and the upstream fix had already been merged by Linus. Public exploit code then appeared, so Qualys posted the details to oss-security.

The Linux kernel CVE team later assigned CVE-2026-46333. The NVD page lists kernel.org as the source, and the description maps to the kernel commit ptrace: slightly saner 'get_dumpable()' logic.

In simple terms, the bug sits in a process exit path. When some privileged processes are exiting, ptrace-related access-check logic in the kernel may bypass a dumpable check that should have applied because the target task no longer has an mm. An attacker can race a very narrow timing window and obtain file descriptors that the exiting privileged process still has open.

That is why the issue is called ssh-keysign-pwn: one public exploitation path uses ssh-keysign to read SSH host private keys.

Why SSH host private keys and /etc/shadow may be exposed

At its core, this is a local information disclosure issue. It abuses a window during privileged process exit where the memory descriptor is gone, but file descriptors have not yet been closed.

The AlmaLinux advisory explains the risk clearly: if a privileged program opened sensitive files before dropping privileges, and an attacker successfully grabs the corresponding file descriptor during the exit window, those sensitive files may become readable.

Two commonly discussed targets are:

ssh-keysign: may involve SSH host private keys such as /etc/ssh/ssh_host_*_key.
chage: may involve /etc/shadow.

If SSH host private keys leak, an attacker may impersonate the host and undermine SSH host identity trust. If /etc/shadow leaks, an attacker can crack password hashes offline and expand the compromise later.

That is why this should be treated as high priority even though it is not a “direct root shell” bug.

How to assess exposure

From the upstream perspective, this is a Linux kernel vulnerability. NVD records show the issue entered the NVD dataset on May 15, 2026, with no CVSS score assigned at that time.

Distribution status should be checked against each vendor’s own advisory:

AlmaLinux 8, 9, and 10 published guidance and updated it on May 16, 2026 to say patched kernels had reached production repositories.
Debian Security Tracker lists vulnerable and fixed states, plus fixed versions, for bullseye, bookworm, trixie, sid, and other branches.
For other distributions, check the official security pages or repositories for Ubuntu, Red Hat, SUSE, Arch, Alpine, and so on.

Do not judge safety only by the upstream kernel version. Distributions backport fixes, so the same upstream-looking version number may mean different patch states across distributions.

Which machines to prioritize

Prioritize remediation in this order:

Multi-user servers and shared hosts.
Bastion hosts, teaching machines, development machines, and other systems with normal shell accounts.
CI runners, build machines, and hosting platform nodes.
Container and virtualization hosts, especially where not-fully-trusted workloads coexist.
Public service machines. The vulnerability needs local access, but the risk compounds once a web bug, RCE, weak password, or similar path gives an attacker a low-privileged foothold.

Pure single-user desktop systems are lower risk, but they should still be updated. Local low-privileged code execution is common on desktops through browsers, developer tools, scripts, and third-party software.

Remediation guidance

The preferred fix is to install the fixed kernel supplied by your distribution and reboot.

Commands differ by distribution, but the principle is the same:

Refresh package metadata.
Install the kernel package containing the CVE-2026-46333 fix.
Reboot into the new kernel.
Use uname -r and the distribution security advisory to verify the running kernel is fixed.

The AlmaLinux advisory says fixed kernels are available in production repositories and users can run the usual dnf upgrade and reboot. The Debian tracker also lists fixed versions for multiple branches.

Important: if you only install a new kernel package but do not reboot, the old vulnerable kernel is still running.

Temporary mitigation: tighten ptrace_scope

If you cannot reboot immediately, tighten Yama ptrace_scope first.

Qualys confirmed in a follow-up oss-security reply that setting /proc/sys/kernel/yama/ptrace_scope to 2 (admin-only attach) or 3 (no attach) blocks the public exploitation paths they know about. They also noted that other theoretical exploitation paths may exist, so this is only a mitigation, not a fix.

Temporary setting:

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

Persistent setting:

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 disables ptrace attach and may affect debugging workflows such as gdb and strace -p. If production debugging is required, evaluate 2. Either way, schedule the kernel upgrade and reboot as soon as possible.

Should SSH host keys be rotated?

Use a conservative approach if the machine had any of the following conditions around the disclosure window:

Untrusted local users.
Shared hosting or container/CI multi-tenant environments.
Web vulnerabilities, weak passwords, supply-chain scripts, or other paths that could give an attacker a local foothold.
Suspicious local processes, unusual debugging behavior, or public PoC files in logs.
Long exposure before patching.

Conservative handling includes:

Rotate SSH host keys after patching and rebooting.
Update known-host fingerprint management systems.
Notify automation that depends on the host fingerprint.
Review SSH connection alerts so legitimate fingerprint changes are not mistaken for man-in-the-middle attacks, and real risks are not ignored.

If /etc/shadow may have leaked, also evaluate password resets, weak-password bans, and whether old hashes could be cracked offline.

What to monitor

The exploitation window is short, so traditional logs may not capture everything. Still, watch for:

Files such as ssh-keysign-pwn, chage_pwn, or similar PoC artifacts in normal user directories.
Suspicious compilation activity, such as unfamiliar C programs compiled in a short window.
Signs of abnormal access to /etc/ssh/ssh_host_*_key or /etc/shadow.
Unusual pidfd_getfd, ptrace, or debugger-related activity.
External reports of unexpected SSH host fingerprint changes.

These signals cannot prove exploitation occurred, and their absence cannot prove it did not. The real priorities remain patching, rebooting, credential rotation, and risk isolation.

Common misconceptions

First: this is not an OpenSSH remote vulnerability. The name includes ssh-keysign, but the root cause is Linux kernel ptrace access-check logic, not the remote authentication path in sshd.

Second: no local users does not mean no risk. The bug does require local execution, but real attack chains often obtain a low-privileged local foothold first through web services, CI, scripts, weak passwords, or container escape paths.

Third: setting ptrace_scope is not enough. It is a temporary mitigation, not the root fix. Kernel update and reboot are still required.

Fourth: “no root shell” does not mean “no incident.” Exposure of SSH host private keys or /etc/shadow can be enough to enable lateral movement, host impersonation, and offline password cracking.

Response checklist

Suggested order:

Inventory affected Linux hosts, especially multi-user and shared environments.
Check distribution security advisories and identify the fixed kernel version.
Install the fixed kernel and reboot.
For machines that cannot reboot immediately, set kernel.yama.ptrace_scope=2 or 3.
After remediation, verify the running kernel version.
Rotate SSH host keys on high-risk machines.
If /etc/shadow exposure is suspected, evaluate password resets and account audits.
Check for public PoCs, unusual compilation, and suspicious local debugging behavior.

Summary

ssh-keysign-pwn (CVE-2026-46333) is a local information disclosure vulnerability rooted in Linux kernel __ptrace_may_access() logic. It does not allow a remote attacker to break in directly and it does not directly grant a root shell, but it may let a low-privileged local user read high-value sensitive files, making it especially important in multi-user, shared hosting, CI, and container-host environments.

The reliable fix is to upgrade to a distribution-provided fixed kernel and reboot. ptrace_scope=2/3 can be used as a temporary mitigation, but it does not replace patching. Critical hosts exposed during the risk window should also be evaluated for SSH host key rotation and password risk.

References:

Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag is a set of Linux kernel local privilege escalation vulnerabilities disclosed in May 2026 with signs of active exploitation. Microsoft describes it as a post-compromise risk: after an attacker gains low-privileged code execution, the bug may be used to escalate to root. Ubuntu has also marked CVE-2026-43284 as High.

The danger is not “remote one-click compromise”. The danger is that once an attacker gets in, they can expand control quickly. If they gain local execution through weak SSH credentials, a web shell, container escape, a low-privileged service account, or phishing-enabled remote access, Dirty Frag may let them obtain root and then disable security tools, read credentials, tamper with logs, move laterally, or persist.

Which CVEs are involved

Public information currently associates Dirty Frag mainly with two IDs:

CVE-2026-43284: related to the Linux kernel xfrm/ESP path. Microsoft’s esp4 and esp6 references belong to this risk area.
CVE-2026-43500: Microsoft says this is related to rxrpc, but as of May 8, 2026, the CVE had not yet been published in NVD and patch status was still evolving.

So do not check only one CVE. A safer approach is to review whether esp4, esp6, rxrpc, and related xfrm/IPsec functions are enabled, needed, and patched by your distribution.

Technical overview

According to Microsoft and Ubuntu, CVE-2026-43284 involves Linux kernel networking and memory-fragment handling, especially how shared page fragments are handled in the ESP/IPsec path.

In simplified terms, data pages can be attached to network buffers through mechanisms such as splice. If later kernel paths treat those fragments as privately owned and safe to modify in place, in-place decryption or modification can happen where it should not. An attacker may manipulate page cache behavior and eventually achieve local privilege escalation.

This has similarities to CopyFail (CVE-2026-31431): both involve Linux page cache behavior, kernel data paths, and local privilege escalation. Dirty Frag is dangerous because it adds more attack paths and may be more reliable than traditional LPE exploits that depend on tight race windows.

Environments to prioritize

Dirty Frag is a local privilege escalation vulnerability, so the attacker must already be able to execute code locally. Prioritize:

Linux servers with exposed SSH.
Web servers where a web shell could be written.
Multi-user login hosts, bastions, developer machines, and CI/CD runners.
Container hosts, Kubernetes nodes, and OpenShift nodes.
Systems using IPsec, VPN, xfrm, or RxRPC-related functionality.
Servers running Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and other mainstream distributions.

If a server has no local multi-user access, no containers, and no exposed application path, risk is lower. But any system where an attacker might obtain a low-privileged shell should treat this as a high-priority kernel issue.

Patch first

The safest fix is to install the kernel security update from your distribution and reboot into the new kernel.

Ubuntu’s CVE page shows CVE-2026-43284 was published on May 8, 2026 and is rated High. Microsoft also says the Linux Kernel Organization has released fixes for CVE-2026-43284 and urges customers to apply patches promptly.

Start by checking the system:

1
2

uname -a
cat /etc/os-release

Then update the kernel using your distribution’s package manager:

`1`	`sudo apt update && sudo apt full-upgrade`

Or:

`1`	`sudo dnf update`

After updating, confirm that the system has rebooted into the new kernel:

`1`	`uname -r`

Installing kernel packages without rebooting leaves the old kernel running, so the vulnerability may still be present.

If patches are not yet available, or production cannot reboot immediately, evaluate whether you can temporarily disable the related modules. Ubuntu’s mitigation blocks esp4, esp6, and rxrpc from loading and unloads them if already loaded.

Create modprobe blocking rules:

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

Update initramfs so the modules are not loaded during early boot:

`1`	`sudo update-initramfs -u -k all`

Unload currently loaded modules:

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

Check whether the modules are still loaded:

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

If a module is in use, unloading may fail. In that case, the block rule may only take effect after reboot.

Evaluate business impact before disabling

Do not paste the mitigation blindly. esp4, esp6, and xfrm/IPsec functionality may be used by VPNs, tunnels, encrypted networking, Kubernetes/container networking, or enterprise network configurations. rxrpc may also affect workloads that depend on that protocol.

Before using the mitigation in production, check at least:

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

If you depend on IPsec VPN or related kernel networking, disabling modules may break connectivity. In that case, schedule kernel patching and a maintenance reboot rather than relying on module blocking for long.

Do not skip post-compromise checks

Microsoft specifically notes that mitigation does not necessarily undo changes already made by successful exploitation. If an attacker already gained root, they may have left persistence, modified files, altered logs, or accessed session data.

At minimum, check:

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

Also review:

Abnormal su, sudo, or SUID/SGID process launches.
Newly created ELF executables.
Suspicious PHP, JSP, or ASP files in web directories.
Changes to SSH authorized_keys.
New persistence in systemd services, cron, or rc.local.
Suspicious privileged containers or host mounts.

If exploitation is suspected, isolate the host, preserve evidence, rotate credentials, and then clean up. Do not assume that unloading modules or clearing caches makes the system safe.

About drop_caches

Microsoft mentions that in some post-exploitation integrity verification scenarios, cache clearing may be evaluated:

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

This is not a vulnerability fix and not an incident cleanup command. Dropping caches can increase disk I/O and affect production performance. Use it only as an auxiliary step after understanding the impact. The real fix remains patching, rebooting, verifying integrity, and checking persistence.

Recommended response order

For production environments, a reasonable response sequence is:

Inventory Linux assets and kernel versions.
Prioritize systems with exposed SSH, web workloads, container hosts, and multi-user access.
Patch and reboot systems that can be restarted quickly.
For systems that cannot yet patch or reboot, evaluate disabling esp4, esp6, and rxrpc.
Increase monitoring for su, SUID/SGID activity, suspicious ELF files, web shells, and container escape indicators.
Run post-compromise checks and rotate credentials on hosts that may already have been exploited.

Summary

Dirty Frag is not a “remote one-click” vulnerability, but it significantly increases post-compromise risk. If an attacker can run code locally with low privileges, CVE-2026-43284 and the related rxrpc attack surface may allow escalation to root.

For administrators, the priority is not studying PoCs. The priority is to confirm kernel exposure, install distribution security updates and reboot, evaluate module-blocking mitigations before the patch window, and inspect exposed or suspicious systems for integrity and persistence issues.

References:

Kernel Security on KnightLi Blog

CVE-2026-43494 / PinTheft: Local Privilege Escalation Risk from Linux RDS and io_uring

What Is the Core Bug?

Why It Is Called PinTheft

The Trigger Conditions Are Not Broad

One-Minute Self-Check

Which Machines Deserve Priority

Temporary Mitigation Ideas

How to Verify After Fixing

References

Impact Summary of Four Recent Linux Local Security Issues: Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn

What the Four Events Affect

Copy Fail: High Priority for Containers and CI Nodes

Dirty Frag: A Post-Compromise Amplifier

Fragnesia: Similar Attack Surfaces Are Not Cleaned Up All at Once

ssh-keysign-pwn: Not Direct Root, Still Dangerous

Shared Impact: Containers Are Not a Strong Boundary by Default

Shared Impact: Patches Must Reach the Running Kernel

Shared Impact: Attack Surface Reduction Must Be Specific

Suggested Response Order

Conclusion

ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk

Bottom line

What the vulnerability is

Why SSH host private keys and /etc/shadow may be exposed

How to assess exposure

Which machines to prioritize

Remediation guidance

Temporary mitigation: tighten ptrace_scope

Should SSH host keys be rotated?

What to monitor

Common misconceptions

Response checklist

Summary

Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide

Which CVEs are involved

Technical overview

Environments to prioritize

Patch first

Interim mitigation: disable related modules

Evaluate business impact before disabling

Do not skip post-compromise checks

About drop_caches

Recommended response order

Summary