Kernel LPE vulnerabilities (Copy Fail, DirtyFrag and Fragnesia) - AKS remediation guidance

# Kernel LPE vulnerabilities (Copy Fail, DirtyFrag and Fragnesia) - AKS remediation guidance

**Update: September 9, 2026**

Fixed AKS node images are available for the Ubuntu and Azure Linux kernel families listed below. **Upgrade existing node pools to a current supported image at or above the applicable minimum; publication of an image does not update existing nodes.** This update supersedes earlier statements in this issue that Ubuntu fixes were still pending.

**Advisory status: open pending release of the Ubuntu 20.04 FIPS module-mitigation cleanup ([Azure/AgentBaker#9431](https://github.com/Azure/AgentBaker/pull/9431)).** Its fixed kernel is already available; the remaining work removes obsolete module restrictions, not a missing kernel security patch. The cleanup release vehicle will be added here before closing this advisory.

| Vulnerability | CVE | Affected module |
|---|---|---|
| Copy Fail | [CVE-2026-31431](https://ubuntu.com/security/CVE-2026-31431) | `algif_aead` |
| DirtyFrag | [CVE-2026-43284](https://ubuntu.com/security/CVE-2026-43284), [CVE-2026-43500](https://ubuntu.com/security/CVE-2026-43500) | `esp4`, `esp6`, `rxrpc` |
| Fragnesia | [CVE-2026-46300](https://ubuntu.com/security/CVE-2026-46300) | `esp4`, `esp6` |

These Linux kernel flaws can allow a local attacker, including an attacker with execution in a container under affected configurations, to escalate privileges. Windows nodes are outside the scope of these Linux kernel vulnerabilities.

## Minimum fixed node images

The minimum applies **within the same OS and kernel family**, not across different image SKUs. Use the newest supported image available in your region rather than pinning to these historical minimums.

| AKS image / kernel family | Minimum fixed VHD | Kernel package in that VHD |
|---|---|---|
| Ubuntu 22.04, standard Azure kernel; Gen1, Gen2, Trusted Launch and ARM64 | **`202606.08.1`** | `5.15.0-1114.123` |
| Ubuntu 22.04 FIPS; Gen1, Gen2 and FIPS Trusted Launch | **`202606.08.1`** | `5.15.0-1114.123+fips1` |
| Ubuntu 24.04, standard Azure kernel; Gen1, Gen2, Trusted Launch and ARM64 **when booted with the standard `-azure` kernel** | **`202606.08.1`** | `6.8.0-1059.65` |
| Ubuntu 20.04 FIPS; Gen1 and Gen2 | **`202606.08.1`** | `5.4.0-1164.170+fips1` |
| Ubuntu 24.04 confidential VM, Azure FDE kernel | **`202606.08.1`** | `6.8.0-1058.65` |
| Azure Linux 3.0, standard host kernel; Gen1, Gen2, ARM64, FIPS, Trusted Launch and CVM variants | **`202605.27.0`** | `6.6.139.1-1.azl3` |

Ubuntu 20.04's 5.4 kernel is not affected by Fragnesia; the listed FIPS image contains the fixes needed for the other CVEs. Its inclusion documents the historical remediation floor and does not extend OS support.

**Sources:** Ubuntu [22.04 image packages](https://github.com/Azure/AKS/blob/master/vhd-notes/aks-ubuntu/AKSUbuntu-2204/202606.08.1.txt), [24.04 image packages](https://github.com/Azure/AKS/blob/master/vhd-notes/aks-ubuntu/AKSUbuntu-2404/202606.08.1.txt), [22.04 FIPS packages](https://github.com/Azure/AgentBaker/blob/main/vhdbuilder/release-notes/AKSUbuntu/gen2/2204fipscontainerd/202606.08.1.txt), [20.04 FIPS packages](https://github.com/Azure/AgentBaker/blob/main/vhdbuilder/release-notes/AKSUbuntu/gen2/2004fipscontainerd/202606.08.1.txt), [24.04 CVM packages](https://github.com/Azure/AgentBaker/blob/main/vhdbuilder/release-notes/AKSUbuntu/gen2/2404cvmcontainerd/202606.08.1.txt), and [Azure Linux 3.0 image packages](https://github.com/Azure/AKS/blob/master/vhd-notes/AzureLinuxv3/202605.27.0.txt).

The Ubuntu images were published in the [AKS June 19 release](https://github.com/Azure/AKS/releases/tag/2026-06-19). The standard/FIPS kernel fixes are recorded on Canonical's CVE pages linked above. For Ubuntu 24.04 FDE, the [matching Canonical package changelog](https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-azure-fde/linux-azure-fde_6.8.0-1058.65/changelog) records Copy Fail and both DirtyFrag/Fragnesia fixes; this is separate evidence from the standard Azure kernel's version number. Azure Linux 3.0 remediation and module-policy changes are tracked in [Azure/AgentBaker#8546](https://github.com/Azure/AgentBaker/pull/8546).

## Module mitigation removal: a separate release milestone

| Configuration | Status of AgentBaker's temporary module restrictions |
|---|---|
| Ubuntu 22.04 / 24.04, covered kernel families | Kernel-aware cleanup already shipped in **AgentBaker `v0.20260729.1`**, targeting **VHD `202607.29.0`**. The VHD patch suffix is `.0`, not `.1`. |
| Ubuntu 20.04 FIPS | Kernel-fixed since **`202606.08.1`**, but released scripts still retain the restrictions. Cleanup is proposed in **[Azure/AgentBaker#9431](https://github.com/Azure/AgentBaker/pull/9431)** for running `5.4.0-*-azure-fips` kernels at ABI 1164 or newer; **the PR is not yet merged and no released cleanup VHD is claimed**. |
| Azure Linux 3.0, standard host kernel | The four-module restriction was omitted from new builds starting with **`202605.27.0`**. Existing restrictions are not actively removed by the Azure Linux runtime CSE path. |

Ubuntu cleanup is implemented by [Azure/AgentBaker#8997](https://github.com/Azure/AgentBaker/pull/8997) and [Azure/AgentBaker#9054](https://github.com/Azure/AgentBaker/pull/9054), both included in the [published AgentBaker release](https://github.com/Azure/AgentBaker/releases/tag/v0.20260729.1). VHD `202607.29.0` is listed in the [AKS August 7 release](https://github.com/Azure/AKS/releases/tag/2026-08-07).

For the verified Ubuntu 22.04 Azure/FIPS family, released cleanup uses running-kernel ABI **1116 or newer**, more conservative than the vendor's first fixed ABI 1114. For the verified Ubuntu 24.04 standard Azure/FDE family it uses ABI **1058 or newer**. The July image meets these cutoffs. June's fixed-kernel floor must not be presented as the first image with mitigation removed.

Cleanup is run during provisioning, including the real-node phase used after PIS preprovisioning; it is not a background update to existing nodes. Scriptless provisioning uses the scripts baked into the image. Older script-based CSE can reapply restrictions even with a newer image, so consuming the corresponding provisioning implementation matters as well as the kernel and image.

### Important exclusions

**Do not remove mitigation merely because an image version is newer than the table.** The following are not covered by its fixed-kernel assurance:

- **Ubuntu ARM64 using an Azure NVIDIA kernel.** Images can contain both standard Azure and NVIDIA kernels. In particular, `6.14.0-1007-azure-nvidia` is not covered by the standard Ubuntu 24.04 fix. Check the kernel actually running.
- **Ubuntu 20.04 confidential VM / other unlisted FDE kernel families.** Do not reuse the standard/FIPS or Ubuntu 24.04 FDE thresholds for another kernel family.
- **Azure Linux OSGuard (`kernel-ipe`).** Retain its existing module restrictions; the standard Azure Linux kernel threshold does not apply to it.
- **Kata guest kernels (`kernel-uvm` / `kernel-mshv`).** The Azure Linux row covers the node host kernel, including hosts running Kata, not the separate guest kernel. Do not infer a guest-kernel fix from the host image version.
- **Azure Linux 2.0 / Mariner and other unlisted or unsupported streams.** No fixed-image minimum is asserted here. Keep applicable protection in place and migrate unsupported pools to a supported OS.

For an excluded configuration that requires the affected modules, contact Azure Support for configuration-specific guidance rather than bypassing the restrictions.

## Update existing node pools

Check the pool's current image and the newest image offered in its region:

```bash
az aks nodepool show \
--resource-group \
--cluster-name \
--name \
--query nodeImageVersion -o tsv

az aks nodepool get-upgrades \
--resource-group \
--cluster-name \
--nodepool-name \
--query latestNodeImageVersion -o tsv
```

Perform a node-image-only upgrade for each affected pool, using your normal maintenance, surge and disruption-budget process:

```bash
az aks nodepool upgrade \
--resource-group \
--cluster-name \
--name \
--node-image-only
```

After the rollout, inspect **every node**, not just pool metadata:

```bash
kubectl get nodes -o custom-columns='NAME:.metadata.name,IMAGE:.metadata.labels.kubernetes\.azure\.com/node-image-version,KERNEL:.status.nodeInfo.kernelVersion'
```

Confirm the image meets its applicable minimum and the running kernel belongs to the covered family. Installing a package without booting the fixed kernel is insufficient. See [AKS node-image upgrades](https://learn.microsoft.com/azure/aks/upgrade-node-image) and the [AKS release tracker](https://releases.aks.azure.com/) for upgrade and regional availability guidance.

## Retiring temporary module mitigation

Kernel remediation and removal of historical module restrictions are separate. A patched kernel can remain protected from exploitation even while a legacy blacklist still blocks legitimate module use.

Only retire the advisory's temporary mitigation after **all nodes it protects** are on confirmed fixed kernels, including any pools it targets through automation. Older/unverified configurations must keep the applicable protection.

If you deployed the self-service `kernel-lpe-mitigate` or legacy `cve-2026-31431-mitigate` DaemonSet, first update its deployment source so it will not be recreated, then remove that specific deployment once the covered nodes are fixed. **Deleting the DaemonSet does not delete the host configuration it already wrote.** The advisory's combined DaemonSet used `/etc/modprobe.d/disable-kernel-lpe.conf`.

Prefer node replacement with an image/provisioning combination that no longer applies the temporary rules. If restrictions persist on confirmed fixed nodes, identify the owner of each configuration file before changing it. Do not delete entire CIS configuration files, clear all modprobe rules, or remove Canonical/package-managed policy. Do not apply host-rule cleanup to excluded pools.

For nodes still relying on mitigation, blocking future module loads does **not** neutralize a vulnerable module that is already loaded. Follow the applicable mitigation procedure, including safe unloading or reboot/node replacement. Conversely, absence of a blacklist on a fixed kernel does **not** indicate vulnerability.

> 🤖 *Generated by GitHub Copilot*