RHSB-2026-003 Networking subsystem Privilege Escalation - Linux Kernel (Dirty Frag) - (CVE-2026-43284)

Executive Summary

Two vulnerabilities, collectively known as "Dirty Frag", have been identified in networking subsystems of the Linux kernel. Due to similarities with the Copy Fail vulnerability, Dirty Frag is also referred to as "Copy Fail 2". A user with a local account could trigger the flaws to gain root privileges, such as that of a system administrator.

Dirty Frag refers to two distinct issues in the IPsec ESP (esp4/esp6) and rxrpc modules. IPsec provides encrypted network communication and is commonly used for VPNs and site-to-site tunnels. The rxrpc module implements the RxRPC protocol, which underpins AFS (Andrew File System), a distributed network filesystem that lets users access files stored on remote servers as if they were local. The IPsec ESP issue has been assigned CVE-2026-43284 and the rxrpc issue has been assigned CVE-2026-43500 (this CVE page may not be available yet). Both have a severity impact of Important. Configuration settings can be used to further mitigate the impact.

Even though the severity is less than Critical, Red Hat is expediting the release of fixes. Click the "Follow" button below to be notified of updates.

Affected Products

While investigation is still ongoing, we can confirm the following products are affected:

• Red Hat Enterprise Linux 10, 9, 8
• OpenShift 4

Mitigations

Overall Guidance

Any hardening measures that limit local access help reduce the risk of exploitation. Examples include disabling SSH, ensuring SELinux is in enforcing mode, using the default Security Context Constraints (SCC), running workloads as non-root, and restricting oc debug access to trusted cluster administrators. This list is not exhaustive, and the applicability of each measure should be evaluated in the context of your operational requirements and security policies. Additionally, disabling any single access method does not eliminate all other means by which a user could gain local access.

Blocklist Method

This advice is applicable to most Red Hat products. The affected modules can be blocklisted and unloaded using the steps below.

Determining if IPsec is in use

To check whether your system is currently using IPsec, run:

lsmod | grep -E 'esp4|esp6'

If the modules are not loaded, IPsec is not in active use and the blocklist is safe to apply. If the modules are loaded and IPsec is actively configured, the blocklist will prevent IPsec from functioning after the next reboot. In that case, consider the "No Impact to IPsec Method" below. Note that even if the modules are loaded, rmmod will refuse to unload them if they are in active use. No running IPsec connections will be disrupted by the command itself.

Warning: Blocklisting esp4/esp6 will break IPsec functionality. Blocklisting rxrpc will break AFS client connectivity. Evaluate the impact on your environment before applying.

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null; true

To revert, remove /etc/modprobe.d/dirtyfrag.conf.

No Impact to IPsec Method

Alternatively, for environments where IPsec must remain functional, the ESP variant (CVE-2026-43284) can be blocked by disabling unprivileged user namespaces:

Warning: This only blocks the ESP variant. On RHEL 9 and 10, the rxrpc variant (CVE-2026-43500) remains exploitable unless rxrpc is also blocklisted as shown above. Disabling unprivileged user namespaces may also affect rootless containers, sandboxed browsers, and Flatpak.

echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf
sysctl --system

Product-Specific Mitigation Steps

• OpenShift 4