GHSA-M38G-VWW2-MVGX
Vulnerability from github – Published: 2026-05-07 02:38 – Updated: 2026-06-08 23:43Summary
A vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets.
The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod.
Impact
An attacker with the ability to deploy a Kubernetes pod on an affected node can:
- Corrupt the page-cache of /usr/sbin/nft in the containerd snapshot layer shared between the attacker's pod and the kube-proxy DaemonSet. Because containerd reuses XFS page-cache pages across overlayfs mounts sharing the same lower layer, the corruption is immediately visible to all containers using that image layer — including privileged system DaemonSets.
- Execute arbitrary code inside kube-proxy — a privileged DaemonSet running on every node with all Linux capabilities (privileged: true) and host network access — the next time kube-proxy invokes nft as part of its nftables reconciliation loop (typically within seconds).
- At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
- Same attack can be planted by infiltrating other binaries running as privileged, for example a CNI plugin.
Patches
Upgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards.
Workarounds
There are multiple workarounds available based on the situation, but we really recommend to upgrade.
Option 1 - Change kernel arguments
Add a kernel argument with initcall_blacklist=algif_aead_init by upgrading Talos to the same version.
Note: this either requires setting
machine.kernel.extraKernelArgsif using BIOS based boot or upgrading with a new image from factory/imager generated image by setting the extra kernel args. See Boot Assets
Option 2 - Deploy all workload pods with a seccomp profile denying creating AF_ALG socket creation
patch.yaml
machine:
seccompProfiles:
- name: copy-fail-block.json
value:
defaultAction: SCMP_ACT_ALLOW
syscalls:
- names:
- socket
action: SCMP_ACT_ERRNO
args:
- index: 0
value: 38
op: SCMP_CMP_EQ
Apply this patch to all machines in the cluster and set this for all the pod spec:
...
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/copy-fail-block.json
Option 3 - Block the syscall in runtime with a eBPF program
See copy-fail-blocker, this can be applied to a running system without a reboot, but it has to run before any other workloads are scheduled after a reboot.
References
- https://copy.fail/
- https://xint.io/blog/copy-fail-linux-distributions
- https://github.com/theori-io/copy-fail-CVE-2026-31431
- https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siderolabs/talos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-669"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T02:38:02Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nA vulnerability in the Linux kernel\u0027s algif_aead subsystem (CVE-2026-31431, \"copy.fail\") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. \n\nThe exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod.\n\n### Impact\n\nAn attacker with the ability to deploy a Kubernetes pod on an affected node can:\n\n1. Corrupt the page-cache of /usr/sbin/nft in the containerd snapshot layer shared between the attacker\u0027s pod and the kube-proxy DaemonSet. Because containerd reuses XFS page-cache pages across overlayfs mounts sharing the same lower layer, the corruption is immediately visible to all containers using that image layer \u2014 including privileged system DaemonSets.\n2. Execute arbitrary code inside kube-proxy \u2014 a privileged DaemonSet running on every node with all Linux capabilities (privileged: true) and host network access \u2014 the next time kube-proxy invokes nft as part of its nftables reconciliation loop (typically within seconds).\n3. At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.\n4. Same attack can be planted by infiltrating other binaries running as privileged, for example a CNI plugin.\n\n### Patches\n\nUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards.\n\n### Workarounds\n\nThere are multiple workarounds available based on the situation, but we really recommend to upgrade.\n\n#### Option 1 - Change kernel arguments\n\nAdd a kernel argument with `initcall_blacklist=algif_aead_init` by upgrading Talos to the same version.\n\n\u003e Note: this either requires setting `machine.kernel.extraKernelArgs` if using BIOS based boot or upgrading with a new image from factory/imager generated image by setting the extra kernel args. See [Boot Assets](https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/boot-assets)\n\n#### Option 2 - Deploy all workload pods with a seccomp profile denying creating `AF_ALG` socket creation\n\n`patch.yaml`\n\n```yaml\nmachine:\n seccompProfiles:\n - name: copy-fail-block.json\n value:\n defaultAction: SCMP_ACT_ALLOW\n syscalls:\n - names:\n - socket\n action: SCMP_ACT_ERRNO\n args:\n - index: 0\n value: 38\n op: SCMP_CMP_EQ\n```\n\nApply this patch to all machines in the cluster and set this for all the pod spec:\n\n```yaml\n...\nspec:\n securityContext:\n seccompProfile:\n type: Localhost\n localhostProfile: profiles/copy-fail-block.json\n```\n\n#### Option 3 - Block the syscall in runtime with a eBPF program\n\nSee [copy-fail-blocker](https://github.com/cozystack/copy-fail-blocker), this can be applied to a running system without a reboot, but it has to run before any other workloads are scheduled after a reboot. \n\n### References\n\n* https://copy.fail/\n* https://xint.io/blog/copy-fail-linux-distributions\n* https://github.com/theori-io/copy-fail-CVE-2026-31431\n* https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC",
"id": "GHSA-m38g-vww2-mvgx",
"modified": "2026-06-08T23:43:27Z",
"published": "2026-05-07T02:38:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/security/advisories/GHSA-m38g-vww2-mvgx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31431"
},
{
"type": "WEB",
"url": "https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC"
},
{
"type": "PACKAGE",
"url": "https://github.com/siderolabs/talos"
},
{
"type": "WEB",
"url": "https://github.com/theori-io/copy-fail-CVE-2026-31431"
},
{
"type": "WEB",
"url": "https://xint.io/blog/copy-fail-linux-distributions"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Talos Linux has a local privilege escalation from untrusted workloads"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.