{
  "is": "issue",
  "title": "copy.fail (CVE-2026-31431)",
  "body": "\u003cp\u003eWe were made aware of \u003ca href=\"https://app.opencve.io/cve/CVE-2026-31431\"\u003eCVE-2026-31431\u003c/a\u003e on the afternoon of the 29th April\nvia our threat intelligence feeds and later via a\n\u003ca href=\"https://cert.europa.eu/publications/security-advisories/2026-005/\"\u003eCERT-EU advisory\u003c/a\u003e.\nThis affected our systems running Rocky Linux 9 as well as our legacy systems running Debian 13.\nPatches were not immediately available however migrations could be applied.\u003c/p\u003e\n\u003ch2 id=\"rocky-linux-9\"\u003eRocky Linux 9\u003c/h2\u003e\n\u003cp\u003eMost of our core systems, including those supporting internal infrastructure and single-sign on, are running Rocky\nLinux 9. This is based on Red Hat Enterprise Linux 9.\nUnfortunately, the kernel does not have the \u003ccode\u003ealgif_aead\u003c/code\u003e subsystem compiled as a module and our only option was to\nprevent the code from initialising via adding kernel arguments at boot time and subsequently rebooting.\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003egrubby --update-kernel\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003eALL --args\u003cspan style=\"color:#f92672\"\u003e=\u003c/span\u003e\u003cspan style=\"color:#e6db74\"\u003e\u0026#34;initcall_blacklist=algif_aead_init\u0026#34;\u003c/span\u003e\nreboot\n\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eOur Prometheus-based monitoring was able to verify all services returning after reboots.\u003c/p\u003e\n\u003ch2 id=\"debian-13\"\u003eDebian 13\u003c/h2\u003e\n\u003cp\u003eSome Link Secure Digital Helpdesks hosted on behalf of the Centre for Digital Resilience use our legacy deployment\nmodel.\nFor these systems we were able to remove the offending module without requiring a reboot:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003eecho \u003cspan style=\"color:#e6db74\"\u003e\u0026#34;install algif_aead /bin/false\u0026#34;\u003c/span\u003e \u0026gt; /etc/modprobe.d/disable-algif-aead.conf\nrmmod algif_aead 2\u0026gt;/dev/null\n\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003ch2 id=\"verification\"\u003eVerification\u003c/h2\u003e\n\u003cp\u003eTo ensure that the mitigation was applied across all hosts, we use Ansible:\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4\"\u003e\u003ccode class=\"language-yaml\" data-lang=\"yaml\"\u003e    - \u003cspan style=\"color:#f92672\"\u003ename\u003c/span\u003e: \u003cspan style=\"color:#ae81ff\"\u003eVerify CVE-2026-31431 mitigation\u003c/span\u003e\n      \u003cspan style=\"color:#f92672\"\u003eansible.builtin.command\u003c/span\u003e: \u003cspan style=\"color:#e6db74\"\u003e\u0026#34;lsmod | grep -E \u0026#39;^{{ item }}\\\\s\u0026#39;\u0026#34;\u003c/span\u003e\n      \u003cspan style=\"color:#f92672\"\u003eloop\u003c/span\u003e:\n        - \u003cspan style=\"color:#ae81ff\"\u003ealgif_aead\u003c/span\u003e \u003cspan style=\"color:#75715e\"\u003e# copy fail\u003c/span\u003e\n      \u003cspan style=\"color:#f92672\"\u003eregister\u003c/span\u003e: \u003cspan style=\"color:#ae81ff\"\u003emodule_check\u003c/span\u003e\n      \u003cspan style=\"color:#f92672\"\u003efailed_when\u003c/span\u003e: \u003cspan style=\"color:#ae81ff\"\u003emodule_check.rc != 1\u003c/span\u003e\n      \u003cspan style=\"color:#f92672\"\u003echanged_when\u003c/span\u003e: \u003cspan style=\"color:#66d9ef\"\u003efalse\u003c/span\u003e\n      \u003cspan style=\"color:#f92672\"\u003echeck_mode\u003c/span\u003e: \u003cspan style=\"color:#66d9ef\"\u003efalse\u003c/span\u003e\n\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eWe do not run any systems where unrelated users have shell access to the host, meaning that this could only have been\nused as part of a chain of vulnerabilities first involving obtaining remote code execution as a user. For this reason\nwe do not believe any exploitation was possible in our systems.\u003c/p\u003e\n\u003cp\u003eFurther, an\n\u003ca href=\"https://garrido.io/notes/podman-rootless-containers-copy-fail/\"\u003eanalysis of the protections offered by Podman\u003c/a\u003e\npublished shortly after by Gabriel Garrido details how our new deployment architecture would further have limited\nthe \u0026ldquo;blast radius\u0026rdquo; of this kind of vulnerability should an exploitation have been possible.\u003c/p\u003e\n\u003cp\u003eIn light of this, we will be prioritising a move of the remaining Link helpdesks using the legacy model to our new\nRocky Linux 9 model.\u003c/p\u003e\n\u003cp\u003eAs always, if you have any concerns please \u003ca href=\"https://www.sr2.uk/support\"\u003econtact our helpdesk\u003c/a\u003e.\u003c/p\u003e\n",
  "createdAt": "2026-04-29 09:00:00 +0000 UTC",
  "lastMod": "2026-05-22 11:02:44 +0100 +0100",
  "permalink": "https://status.sr2.uk/issues/2026-04-29-copy-fail/",
  "severity": "disrupted",
  "resolved": true,
  "informational": false,
  "resolvedAt": "2026-05-01 12:00:00",
  "affected": ["API", "Single-Sign On", "Virtual Servers", "Link Helpdesks"],
  "filename": "2026-04-29-copy-fail.md"
}