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

Public Date: May 7, 2026, 15:36
Updated May 21, 2026, 18:58

Was this information helpful?

Feedback cancelled

Ongoing Status
Important Impact

Executive Summary

Three vulnerabilities, collectively known as "Dirty Frag", have been identified in networking subsystems of the Linux kernel, two of which affect Red Hat products. Due to similarities with the Copy Fail vulnerability, Dirty Frag is also referred to as "Copy Fail 2". A recently disclosed variant, referred to as "Fragnesia", has been identified as part of the Dirty Frag vulnerability set. 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 three distinct issues in the IPsec ESP/XFRM (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 following CVEs have been assigned, all with 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

The following products are affected:

  • Red Hat Enterprise Linux 10, 9, 8

Further, any Red Hat product that relies on the Red Hat Enterprise Linux kernel (including RHEL CoreOS) is also potentially impacted. This includes layered products such as Red Hat OpenShift Container Platform, Red Hat OpenStack Platform, and Red Hat Virtualization.

Please ensure that the underlying Red Hat Enterprise Linux kernel is current in these product environments.

Mitigation

Overall Guidance

The mitigation methods below address both vulnerabilities that affect Red Hat products — CVE-2026-43284 (IPsec ESP) and CVE-2026-46300 (XFRM ESP-in-TCP). CVE-2026-43500 (rxrpc) does not affect Red Hat products and requires no mitigation.

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.

Broader Method - Block IPsec Module

This advice is applicable to most Red Hat products. The affected modules can be blocked 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 it is safe to block the modules. If the modules are loaded and IPsec is actively configured, blocking the modules will prevent IPsec from functioning after the next reboot. In that case, consider the Targeted Method described 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: Blocking esp4/esp6 will break IPsec functionality. Evaluate the impact on your environment before applying.

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

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

Targeted Method - Preserve IPsec Functionality

Alternatively, for environments where IPsec must remain functional, both vulnerabilities can be mitigated by disabling unprivileged user namespaces.

Warning: 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

Was this information helpful? Your feedback is valuable!

Feedback cancelled

Comments