Copy Fail is a local privilege escalation exploit. Here is what CIQ did about it.

CVE-2026-31431 affects kernels built since 2017 and has a working public exploit in circulation. Patched kernels are available now for every CIQ-supported Rocky Linux variant.

The vulnerability: CVE-2026-31431 "Copy Fail"

On April 29, 2026, security researchers at Theori disclosed CVE-2026-31431, a local privilege escalation vulnerability in the Linux kernel's crypto/algif_aead subsystem, quickly named "Copy Fail." CISA added it to the Known Exploited Vulnerabilities catalog on May 1. The Common Vulnerability Scoring System (CVSS) score is rated as a 7.8 CVSS.

The mechanics made it notable. An unprivileged local user could write four controlled bytes into the page cache of any readable file on the system and use that write to gain root. The technique required no race condition and carried no per-distribution offsets, which meant the proof-of-concept exploit worked broadly across affected kernels. Reimplementations in C, Go, and arm64 followed the initial Python script within days. The same page-cache manipulation that drove the escalation also bypassed on-disk file-integrity tools and crossed container boundaries.

The patch set addressed three related CVEs across 10 commits: CVE-2026-31431 covering the core algif_aead out-of-place operation, CVE-2026-23060 covering authencesn AAD validation, and CVE-2026-31677 covering af_alg page handling overflow.

The response

Our kernel team began work on Wednesday, April 29, the same day that the Copy Fail exploit was publicly disclosed. Our kernel engineers started the process of determining the right way to patch while our support organization worked on mitigation strategies. By Thursday morning, we had a clear mitigation that we were sending to customers through a Knowledge Base article.

Copy Fail also published a mitigation to add the affected module "algif_aead" to the modprobe.d blacklist. This mitigation didn't work for EL kernels because the EL kernels have the affected code built into the kernel rather than having it built as a module. The user Curious from the Rocky Linux Community is credited with developing the mitigation that we shipped to customers. The mitigation caused the kernel to short-circuit the module built in. The downside to the mitigation is that it required adding a kernel command line argument and rebooting. CIQ wanted to move quickly so that customers could stage a fixed kernel.

On Thursday, we had the first patch that failed testing due to a kernel crash but stopped the exploit. As we continued to dig into the cause of the crash, we found that there was a set of patches that included 2 additional CVEs and some bug fixes to make the kernel stable and prevent the exploit from happening.

Kernel work is never done in a vacuum. Our kernel team relied on the patches from upstream which provided the basis for the patches we had created. We realized that we were developing almost the same set of patches as was proposed in the CentOS stream kernels. Our patch set was based on 7 upstream commits, whereas the CentOS fix was based on 9. Our patch set included one commit that wasn't included in the CentOS fix that was required to fix a bug. We notified CentOS of the additional fix and included the other commits from CentOS in our patch set. This meant that when the EL kernels caught back up to the kernels we were shipping, the changes would be aligned. By Friday afternoon (May 1), we had released kernels for RLC LTS 9.2, 9.4, and 9.6 with the fixes applied and tested against our CI pipeline and the exploit.

From there, the work continued through the weekend. RLC LTS 8.6 was released on Saturday. RLC 8.10 FIPS was released on Sunday. On Monday, the focus was releasing kernels for customers that are running on the latest version of Rocky Linux from CIQ. This included RLC 8.10, RLC 9.7, SCN 8, and SCN 9. On Tuesday, May 5, we released the fixed kernels for SCN 10. The last kernel was the CLK 6.12 kernel that was released on Thursday, May 7. The scope covered four kernel major versions: 4.18 for EL8, 5.14 for EL9, 6.12 for EL9, and 6.12 for EL10. The full list included RLC 9.7 and 8.10, RLC Hardened 9.7, RLC LTS across 9.2, 9.4, 9.6, 8.6, and 8.10, RLC FIPS Compliant 8.10 and 8.6, and SIG Cloud Next 8, 9, and 10.

Every kernel carried the same set of upstream commits adapted to each kernel version. Kernel engineering, support engineering, Customer Success, and security advisory functions all ran in parallel against a real-time shared status channel, so that every build, promotion, and verification step stayed visible across teams and nothing dropped between handoffs. The knowledge base article was updated to keep customers informed as kernels were released.

CIQ's commitment to customers was that no matter which version you are running, we want to make sure that you are secure. We focused on delivering the fixed kernels to all of our customers, whether running the latest Rocky Linux or a Long Term Support version.

What to do

The patched kernel for your variant is available now. For most LTS and FIPS customers, the update requires dnf update kernel* and a reboot, with no additional repository changes. RLC Pro 8, RLC Pro 9, and LTS 8.10 customers need the Core Repo enabled through Depot before running the update. The full KB article covers exact patched kernel versions for every supported variant, verified installation steps, the boot-parameter mitigation for systems that cannot update immediately, and instructions for reverting that mitigation once the patch is in place. If you need help validating exposure across a fleet or confirming patch compatibility with your workload, open a support case and we will work through it with you.

Read the KB article