HVENS response to Dirty Frag (CVE-2026-43284, CVE-2026-43500)

One week after Copy Fail, the Linux kernel has another local privilege escalation in the wild. The new flaw, nicknamed Dirty Frag, was published on May 7 by researcher Hyunwoo Kim and chains two related page-cache write bugs in the kernel's networking stack: CVE-2026-43284 in the IPsec ESP receive path (esp4/esp6) and CVE-2026-43500 in rxrpc. Together they give an unprivileged local user a deterministic path to root on every major distribution shipping a kernel from the last nine years, and on container hosts they also enable container escape.

If you read our Copy Fail writeup last week, the shape of this one will look familiar. There are two important differences worth flagging up front:

• The Copy Fail mitigation does not cover Dirty Frag. Hosts that were hardened by blacklisting algif_aead are still exploitable through esp4, esp6, or rxrpc. This is a separate fix.
• Reliability is higher. Dirty Frag is a logic bug rather than a race, so there is no timing window to lose, the kernel does not panic on a failed attempt, and public PoC code already exists.

For the technical writeup, see Bleeping Computer, The Hacker News, or Red Hat's RHSB-2026-003 security bulletin.

Core platform - mitigated

As with Copy Fail, our hypervisors, storage controllers, control plane, and management network in both Ashland and Denton were the first systems we touched. The vendor-recommended blacklist (esp4, esp6, and rxrpc) has been pushed to every host through configuration management, and the affected modules have been unloaded from running kernels where they were present. Because Dirty Frag does not share a mitigation with Copy Fail, this is a brand-new rollout - not an extension of last week's work.

None of these modules are part of how HVENS Cloud carries customer traffic. We use EVPN for tenant segmentation rather than IPsec, and rxrpc is an AFS protocol that we do not run on the platform, so removing them did not affect production traffic. There was no service impact.

Managed workloads

Customers under a Richweb managed-services agreement had the same blacklist applied to their VMs and managed equipment in the same maintenance pass. If you are fully managed, this one is already done on your behalf - no action needed. If your managed environment legitimately uses IPsec (site-to-site VPN, for example) or AFS, your account engineer has already been in touch about a tailored mitigation that keeps those services up while still closing the hole; if you have not heard from us and you think you should have, please reach out.

Self-managed VMs - your turn

For VMs you operate yourself inside HVENS, the kernel inside the VM is yours to patch. We do not have the access to mitigate Dirty Frag from our side without crossing the management boundary you've asked us to respect. A few specifics worth knowing while you plan your response:

• The Copy Fail blacklist is not sufficient. You need a separate change for Dirty Frag.
• Disabling unprivileged user namespaces blocks the ESP half of the chain but leaves the rxrpc half exploitable on RHEL 9 and 10. On those distributions you should blacklist rxrpc as well unless you have a specific reason to keep it.
• Blacklisting esp4/esp6 will break IPsec VPNs running inside the VM. If that is load-bearing for you, plan around the upstream patch instead of the temporary mitigation.
• If your VM runs containers with untrusted workloads, treat this as a container escape, not just a local LPE.

If you are not certain whether a given VM is managed or self-managed, ask Richweb's helpdesk and we will confirm in writing. We are also seeing some customers move from self-managed to managed coverage off the back of the last two weeks of CVEs - happy to quote that as well.

Patch rollout

The upstream patch for the ESP bug landed in the netdev tree on May 7 and has begun appearing in distro repositories. The rxrpc patch is still pending upstream at the time of writing. As soon as both are available in the channels we track, we will schedule the patch-and-reboot rollout across our infrastructure and managed customer fleets the same way we are doing it for Copy Fail. The two efforts will be sequenced together where the same host needs both, so customers do not eat two reboots in a row.

Maintenance windows will be announced on status.hvens.com as usual. Self-managed customers should follow their own change-management process when patched kernels reach their distro; we are happy to advise on sequencing if it helps.

Questions

For questions about HVENS' response, whether your environment is covered, or what action you still need to take, contact Richweb's helpdesk or call 804-368-0421. Material updates to our response will be posted here and to the status site as the upstream patches finish landing.

References

• NVD - CVE-2026-43284 - xfrm-ESP page-cache write.
• NVD - CVE-2026-43500 - RxRPC page-cache write.
• Red Hat - RHSB-2026-003 - vendor security bulletin and mitigation guidance.
• Bleeping Computer - New Linux 'Dirty Frag' zero-day with PoC exploit gives root privileges - background and PoC context.
• The Hacker News - Linux kernel Dirty Frag LPE exploit enables root access across major distributions - additional technical writeup.
• Ubuntu - Dirty Frag Linux kernel local privilege escalation mitigations - distro-level advisory; check your own distro's advisory if you self-manage.
• AlmaLinux blog - Dirty Frag patches released - example of a distro patch announcement.

Related

• HVENS response to Copy Fail (CVE-2026-31431) - last week's writeup; mitigation does not overlap with this one.
• Cloud VM hosting for MSPs - what we host and how managed coverage handles patching like this for you.
• Talk to us about managed services if you'd rather not chase vulnerability windows yourself.
• status.hvens.com - live platform status and maintenance windows.