Linux kernel privilege escalation advisory: Copy Fail and Dirty Frag

Status: Active remediation

Severity: High

Last updated: 8 May 2026

Applies to: Linux servers, container hosts, Kubernetes nodes, CI runners, shared hosting systems, and managed infrastructure running affected Linux kernels

Summary

StackTrack is tracking two Linux kernel local privilege escalation vulnerability groups: Copy Fail and Dirty Frag.

We are grouping these issues in one support notice because they affect the same operational risk area: Linux kernel local privilege escalation. In practical terms, the recommended response is similar: apply vendor kernel updates, reboot into the fixed kernel, and use temporary mitigations only where they are safe and appropriate.

These vulnerabilities are not remote code execution vulnerabilities by themselves. An attacker generally needs some existing ability to run code on the system. However, once that foothold exists, these issues may allow escalation to root, which makes them particularly important for shared systems, container platforms, cloud environments, CI runners, and customer-facing infrastructure.

Vulnerabilities covered

Copy Fail, tracked as CVE-2026-31431, is a Linux kernel local privilege escalation vulnerability affecting the algif_aead cryptographic path. CISA added it to the Known Exploited Vulnerabilities catalogue on 1 May 2026, citing active exploitation. (CISA)

Dirty Frag is a newer Linux kernel local privilege escalation vulnerability class affecting kernel paths related to xfrm/ESP and RxRPC. Reporting describes it as a successor to Copy Fail and part of the same broader family of Linux page-cache privilege escalation bugs. (The Hacker News)

Why this matters

A successful exploit may allow a local unprivileged user or compromised workload to gain root privileges on an affected Linux host.

This risk is especially relevant where systems allow code execution by applications, users, CI jobs, containers, or third-party workloads. The practical concern is not only direct local user access, but also the possibility of chaining these vulnerabilities after another compromise. Microsoft’s analysis of Copy Fail highlights the risk across cloud environments and Kubernetes workloads. (Microsoft)

Affected environments may include:

• Linux virtual machines and bare-metal servers
• Container hosts and Kubernetes worker nodes
• CI/CD runners
• Bastion hosts and administrative jump boxes
• Shared hosting platforms
• Managed application servers
• Systems running customer or third-party code
• Systems exposed to the internet where another vulnerability could provide the initial foothold

What StackTrack is doing

For infrastructure managed by StackTrack, we are taking the following actions:

1. Identifying affected Linux hosts and kernel versions.
2. Prioritising internet-facing, shared, containerised, and customer-facing systems.
3. Applying vendor-provided kernel updates where available.
4. Rebooting systems where required to activate patched kernels.
5. Reviewing temporary mitigations where a patch is not yet available.
6. Avoiding mitigations that could disrupt VPN, IPsec, or specialist networking workloads unless the impact has been reviewed.
7. Monitoring for signs of suspicious local privilege escalation activity.

Where live patching is available and appropriate, we may use it to reduce disruption. Where a reboot is required, we will coordinate this according to the impact on the affected service.

Customer impact

For fully managed StackTrack services, we will handle the assessment, patching, mitigation, and reboot process.

Customers may see:

• Scheduled maintenance notifications
• Short service interruptions
• Host reboots
• Workload migration between nodes
• Follow-up questions about VPN, IPsec, AFS, or specialist kernel networking requirements

We will not apply mitigations that could knowingly disrupt critical networking services without first reviewing the role of the affected host.

Recommended action for customers

For StackTrack-managed systems

No immediate action is required unless we contact you directly.

Please respond promptly to any maintenance approval requests, especially where a reboot is needed to complete kernel patching.

You should notify us if any managed system relies on:

• IPsec
• strongSwan or Libreswan
• VPN gateway functionality
• AFS
• RxRPC
• Specialist kernel networking modules
• Custom kernel modules or pinned kernel versions

For systems not managed by StackTrack

We recommend the following:

1. Review your Linux vendor’s security advisory.
2. Apply the latest available kernel updates.
3. Reboot into the patched kernel.
4. Prioritise shared, containerised, internet-facing, and CI/CD systems.
5. Use temporary mitigations only after confirming they will not break required services.
6. Confirm that the running kernel is the patched version after reboot.

On many Linux systems, you can check the running kernel with:

uname -r

For Debian and Ubuntu-based systems:

sudo apt update
sudo apt full-upgrade
sudo reboot

For RHEL-compatible systems:

sudo dnf update
sudo reboot

For systems using live patching, verify that the relevant live patch has been applied using your vendor’s live patch tooling.

Notes on temporary mitigations

Temporary mitigations may be useful where a patched kernel is not yet available or where an immediate reboot is not possible. However, mitigations must be tested carefully.

For Copy Fail, some vendor guidance has focused on blocking or disabling the vulnerable algif_aead module path while kernel fixes are being rolled out. Ubuntu has published guidance for Copy

Fail fixes and mitigations. (Ubuntu)

For Dirty Frag, some mitigations involve disabling affected kernel modules related to ESP/IPsec and RxRPC. This may not be safe on systems that rely on IPsec, VPN tunnels, or related networking functionality. CloudLinux has specifically published Dirty Frag mitigation and kernel update guidance, and its status page identifies Dirty Frag as a Linux kernel local privilege escalation issue in the xfrm subsystem. (cloudlinux.statuspage.io)

Do not apply module blacklisting blindly on production systems. Where possible, prefer vendor kernel updates followed by a reboot.

Current recommendation

Our recommended remediation path is:

1. Patch affected kernels as soon as vendor updates are available.
2. Reboot into the patched kernel.
3. Use temporary mitigations only where patching or rebooting cannot be completed immediately.
4. Prioritise high-risk hosts first: container nodes, CI runners, shared systems, bastion hosts, and internet-facing workloads.

Copy Fail should be treated as urgent because it has been added to CISA’s Known Exploited Vulnerabilities catalogue. Dirty Frag should also be treated as high priority because public proof-of-concept information and reporting indicate a reliable local privilege escalation risk across major Linux distributions. (CISA)

Support

Customers with questions about these vulnerabilities or their managed systems should contact StackTrack support.

Subject: Linux kernel vulnerability support — Copy Fail / Dirty Frag

When contacting support, please include:

• The affected system or service name
• The Linux distribution and version
• The current running kernel version from uname -r
• Whether the system uses IPsec, VPN, AFS, custom kernel modules, or pinned kernels
• Any maintenance window constraints you need us to consider

Updated on: 08/05/2026