Mitigation of CVE-2026-43284, CVE-2026-43500, CVE-2026-46300 (Dirty Frag / Fragnesia) in vSphere Kubernetes Service for Ubuntu Nodes

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

vSphere Kubernetes Service when running with Ubuntu 22.04 and 24.04 is confirmed as affected by CVE-2026-43284, CVE-2026-43500 and CVE-2026-46300 (collectively referred to as “Dirty Frag”) under select circumstances only. Nodes running Photon are not affected.

Environment

vSphere Kubernetes Service

Cause

Two local privilege escalation (LPE) vulnerabilities affecting the Linux kernel were publicly disclosed on May 8, 2026. The vulnerabilities have been assigned CVE IDs CVE-2026-43284, CVE-2026-43500, and CVE-2026-46300 are collectively referred to as "Dirty Frag" and "Fragnesia". The affected components are Linux kernel modules implementing network transport protocols:

Kernel Module	Purpose
esp4	IPSec Encapsulating Security Payload (ESP) processing for IPv4
esp6	IPSec Encapsulating Security Payload (ESP) processing for IPv6
rxrpc	RxRPC transport protocol (used by AFS / kAFS distributed filesystems)

Resolution

1. Impact on vSphere Kubernetes Service

No software package in vSphere Kubernetes Service uses esp4, esp6, or rxrpc. The modules are most frequently used for IPSec VPN tunnels (esp4, esp6) and the Andrew File System / kAFS (rxrpc). Antrea in VKS uses WireGuard for inter-node encryption, so the ESP modules are not loaded under default operation. No VKS component uses these modules.

1.1. Identifying container-level attack surface

Exploitation of the Dirty Frag vulnerabilities requires the CAP_NET_ADMIN Linux capability. Standard containers running in Kubernetes do not have this capability by default; only containers with explicit securityContext.capabilities.add: [NET_ADMIN] or securityContext.privileged: true can exploit these vulnerabilities. 

Most VKS workloads operate under restrictive security contexts, significantly reducing the attack surface from this class of vulnerability. It is possible to verify that no workloads other than Container Network Interface pods in the cluster are running with CAP_NET_ADMIN by searching pod specifications for NET_ADMIN and privileged: true configurations, using the following script:

kubectl get pods -A -o json | jq -r '
  .items[] as $p |
  ($p.spec.containers + ($p.spec.initContainers // []) + ($p.spec.ephemeralContainers // []))[] |
  select(
    .securityContext.privileged == true or
    ((.securityContext.capabilities.add // []) | index("NET_ADMIN"))
  ) |
  [$p.metadata.namespace, $p.metadata.name, .name,
   "privileged=\(.securityContext.privileged // false)",
   "caps=\((.securityContext.capabilities.add // []) | join(","))"
  ] | @tsv
' | column -t

1.2. Finding if an application is using the affected protocols

For esp4 / esp6 (IPSec ESP), check for active IPSec state and policy on the host:

sudo ip xfrm state
sudo ip xfrm policy

Any non-empty output indicates IPSec is in use on the node, which will keep the ESP modules loaded.

For rxrpc, check for processes with AF_RXRPC sockets open. RxRPC socket use is typically associated with AFS / kAFS clients:

sudo lsof -nP 2>/dev/null | awk 'NR==1 || /protocol: RXRPC/'
sudo ss -A rxrpc -p 2>/dev/null || true

Check whether the kAFS filesystem is mounted:

mount | grep -E '\bafs\b' || echo "No AFS mounts found"

 

2. Software Releases

New vKRs will be published in due course with the following Ubuntu kernel versions:

Ubuntu Release	Linux Kernel Version
Ubuntu 22.04	To be determined
Ubuntu 24.04	To be determined

 

3. Mitigation

NOTE: Broadcom strongly recommends testing this mitigation in non-production environment first. 

3.1. Block the modules by creating a /etc/modprobe.d/manual-disable-dirtyfrag.conf file:

sudo tee /etc/modprobe.d/manual-disable-dirtyfrag.conf >/dev/null <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

3.2. Persist mitigation on a workload cluster

To patch an existing workload cluster with the manual mitigation, it is required to identify current pause image, used by the cluster subject to be patched.

• Copy script "disable-dirtyfrag.sh" from attachments to a Linux-machine with kubectl present and logged in to the Supervisor cluster.
• Make the script executable:
  

  chmod +x disable-dirtyfrag.sh

• Generate a DaemonSet YAML file for applying mitigation: (It will not automatically apply the YAML definition)
  

  ./disable-dirtyfrag.sh --namespace <namespace> --cluster <workload-cluster> > daemonset.yaml

• Apply customized YAML on the workload cluster to apply mitigation:
  

  kubectl apply -f daemonset.yaml

This has to be completed for all workload clusters which should be mitigated.

3.3. Does the machine need a reboot?

VKS nodes under normal operation will not need a reboot. A reboot is only needed if one or more of the affected kernel modules is loaded.

3.3.1. Listing every node in the cluster that needs a reboot

The snippet below iterates over all nodes via kubectl debug node/<name>, reads each node's /proc/modules through the host mount, and prints a single line per node. Nodes reporting "REBOOT NEEDED" still have one or more of esp4, esp6, or rxrpc loaded into the running kernel; the blocklist will prevent future loads but the running instances can only be cleared by rmmod or a reboot.

for node in $(kubectl get nodes -o name); do
  name="${node#node/}"
  loaded=$(kubectl debug "$node" -q --image=busybox -- \
    chroot /host sh -c '
      out=""
      for m in esp4 esp6 rxrpc; do
        grep -qE "^${m} " /proc/modules && out="${out}${m},"
      done
      echo "${out%,}"
    ' 2>/dev/null | tail -n1)
  if [[ -n "${loaded:-}" ]]; then
    printf '%-50s %s\n' "$name" "REBOOT NEEDED (loaded: ${loaded})"
  else
    printf '%-50s %s\n' "$name" "OK"
  fi
done

Any node printed as REBOOT NEEDED should be cordoned, drained, and rebooted following the rebooting guidance below. Debug pods are short-lived and will be cleaned up automatically; if the environment restricts kubectl debug, an equivalent check can be run via SSH or any internal automation tools.

3.3.2. Finding out if the kernel module is loaded

On a single node (run via SSH):

awk 'NR==FNR{l[$1]=1; next} {print "Affected module is" (l[$1]?"":" NOT"), "loaded:", $1}' /proc/modules <(printf '%s\n' esp4 esp6 rxrpc)

3.3.3. What to do if the kernel module is loaded

Broadcom recommends applying the mitigation and then rebooting the node. A reboot is the safest way to ensure the modules are no longer present in the running kernel.

If a reboot is not immediately possible, it can be attempted to live unload with rmmod on nodes 

Note that esp4 and esp6 are typically pulled in by the xfrm framework when an IPSec policy is installed; you need to flush IPSec state first

3.3.3.1. Inspect any active IPSec state and policy before flushing

sudo ip xfrm state
sudo ip xfrm policy

3.3.3.2. Flush IPSec state/policy (only do this if you control the host and no IPSec workload is in use)

sudo ip xfrm state flush
sudo ip xfrm policy flush

3.3.3.3. Attempt to unload the modules

sudo rmmod esp4 esp6 rxrpc

3.3.3.4. Check whether the unload succeeded

for m in esp4 esp6 rxrpc; do
  grep -qE "^${m} " /proc/modules && echo "Module is still loaded: ${m}" || echo "Module successfully unloaded: ${m}"
done

Note: rmmod will fail if any process or subsystem holds the module open, and forcibly removing a module that is in use (rmmod -f) risks kernel instability. For this reason, a reboot remains the recommended path even when rmmod appears to succeed.

Guidance on rebooting

Note: If it is chosen to reboot nodes, it is highly recommended to cordon and drain nodes prior to their reboot. This is to reduce any disruptions to running workload.

Before rebooting any node, cordon it with kubectl cordon to stop new pods being scheduled, then drain it with kubectl drain --ignore-daemonsets --delete-emptydir-data to evict running workloads gracefully. Draining honors PodDisruptionBudgets and gives stateful workloads (etcd members, databases, message brokers) the chance to fail over or flush state cleanly; skipping this risks data loss, split-brain, and avoidable downtime.

Confirm the drain has completed and the node reports SchedulingDisabled before issuing the reboot. Reboot one node at a time and wait for it to return to Ready before moving on - this is especially important for control plane nodes, where etcd quorum (n/2 + 1 members) must be preserved throughout. Once the node is healthy, uncordon it with kubectl uncordon so workloads can be scheduled again.

Additional Information

More information about the security vulnerability and impacted VCF products are provided in KB Impact Evaluation of CVE-2026-43284, CVE-2026-43500, and CVE-2026-46300 (Dirty Frag/Fragnesia) of VMware by Broadcom product portfolio.

Should you require further information or support, contact Broadcom Support.
To be notified on any changes, subscribe to this knowledge base article.