How to mitigate the Copy Fail CVE-2026-31431 in OpenShift 4

Solution Verified - Updated 25 May 2026

Environment

Red Hat OpenShift Container Platform (RHOCP)
- 4

Issue

OpenShift Container Platform 4 is confirmed as affected by CVE-2026-31431 ("Copy Fail").
How to mitigate this vulnerability in OpenShift until the fix is implemented?

Resolution

Disclaimer: Links contained herein to external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

List of fixed versions

Red Hat releases OpenShift updates with patched kernels as soon as those are available and have been through standard validation processes. The following versions already contains the fix:

RHOCP Release	Fixed version	Errata
4.21	4.21.14	RHSA-2026:13811
4.20	4.20.21	RHSA-2026:13862
4.19	4.19.30	RHSA-2026:13690
4.18	4.18.40	RHSA-2026:13727
4.17	4.17.53	RHSA-2026:13885
4.16	4.16.61	RHSA-2026:13729
4.15	4.15.64	RHSA-2026:14773
4.14	4.14.65	RHSA-2026:15087
4.13	4.13.66	RHSA-2026:14112
4.12	4.12.89	RHSA-2026:14097

Note: it could take some time to get the versions in the stable channel, but it is possible and supported to upgrade using the fast channel as explained in is switching between Openshift 4 update channels supported?

Mitigation Options

When it is not possible to upgrade a cluster to any of the versions that already include the fix for any reason, below options are provided to block access to the vulnerable kernel functions can be blocked either through a kernel argument or via a DaemonSet which deploys a small eBPF program blocking access.These mitigations can be removed after upgrading to the fixed version of OpenShift.

The eBPF program allows mitigations to be deployed on AMD64 nodes without rebooting the node which may be desirable to avoid workload disruption. However the DaemonSet cannot be assured to be deployed prior to vulnerable workloads during reboots or node scaleup, it may also be evicted per cluster configuration. It is needed to closely monitor DaemonSet health to ensure ongoing protection. This option does not currently deploy on ARM64, ppc64le, or s390x nodes.
The kernel argument is deployed via MachineConfig which means nodes will perform a rolling reboot, this option is not susceptible to raciness or eviction.

Note: The mitigations should NOT be applied to clusters where workload relies AF_ALG socket access to kernel AEAD algorithms. This is not common, but can be used in hardware crypto acceleration use cases. There are currently no other known side effects of this mitigation strategy. Use lsof -w | grep ALG to check a sampling of nodes to determine if any workload is currently using the AF_ALG socket.

1. Mitigation Steps with eBPF `DaemonSet` (NO node reboot required)

Attention: this approach does not currently work on an ARM, ppc64le, and s390x kernels. Red Hat will update this solution if that changes.

OpenShift Engineering has produced a rebootless mitigation which runs a BPF LSM DaemonSet that blocks all AF_ALG AEAD binds on the cluster. Details about the use of the rebootless mitigation are located at the OpenShift Engineering GitHub repository: Content from github.com is not included.block-copyfail

Note: Applying the mitigation DaemonSet will pull the following container image:
       image: registry.redhat.io/openshift4/ose-block-copyfail-rhel9@sha256:2ad45164bed4ef8b8661175ac02e891b8bf2bdcdf69bed3526777b4746c3b46a

As a cluster admin, create the Namespace, RBAC, and DaemonSet from daemonset.yaml:

$ git clone https://github.com/openshift/block-copyfail
$ cd block-copyfail
$ git checkout 6d4ade65b1f0d7eb7d885e76f5732b9532c35999
$ oc apply -f daemonset.yaml
namespace/cve-2026-31431-mitigation-ebpf created
rolebinding.rbac.authorization.k8s.io/system:openshift:scc:privileged created
daemonset.apps/cve-2026-31431-mitigation-ebpf created

Verify DaemonSet READY status matches the node count in the cluster:

$ oc get -n cve-2026-31431-mitigation-ebpf daemonset.apps/cve-2026-31431-mitigation-ebpf
NAME                             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
cve-2026-31431-mitigation-ebpf   6         6         6       6            6           <none>          19s

$ oc get nodes -o name | wc -l
6

2. Or, mitigation steps with Machine Config (node reboot required)

Attention: This procedure will cause a reboot of all nodes targeted by the MC!

This mitigate option will blacklist the algif_aead module. This can be done on OpenShift via a Machine Config:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker 
  name: 99-disable-algif-builtin
spec:
  kernelArguments:
    - initcall_blacklist=algif_aead_init

You will need to create a MachineConfig for each individual MachineConfigPool such as master, worker, and any custom pools created as well. You should run through each pool one at a time.

This will add the following: initcall_blacklist=algif_aead_init to the boot cmd line

# cat /proc/cmdline | grep initcall_blacklist

Verify that algif_aead is disabled at boot via the dmesg logs:

To use host binaries, run `chroot /host`. Instead, if you need to access host namespaces, run `nsenter -a -t 1`.
If you don't see a command prompt, try pressing enter.
sh-5.1# chroot /host
sh-5.1# dmesg | grep -i "blacklisted"
[    1.755072] initcall algif_aead_init blacklisted

3. Partial Privilege Escalation Mitigation with SCCs

The restricted-v2 SCC, which has been the default since OpenShift Container Platform 4.11 whenever allowPrivilegeEscalation: true has not been set, will prevent privilege escalation within that pod. It will not prevent page cache corruption as such it may be possible to alter code execution across all pods on a host, this means another unrestricted pod could be leveraged for privilege escalation. Workloads that can be run under restricted-v2 should be reconfigured to do so reducing risk in general.

To check under which SCC the pod was admitted to the cluster.

$ oc get pod <pod-name> -o jsonpath='{.metadata.annotations.openshift\.io/scc}'

Removing the Mitigation

In order to remove the mitigation, please update to the version containing the fix. Please check the "List of fixed versions".

1. Machine config mitigation

Once the cluster is updated, remove the mitigation by removing the Machine Config from the cluster. The machine-config operator will reconcile the changes and will update all the nodes.

$ oc delete machineconfigs.machineconfiguration.openshift.io 99-disable-algif-builtin

Note: If you created Machine Config for each Machine Config Pool, please remove it as well. The removal of the Machine Config will trigger the reboot of the nodes.

2. eBPF DaemonSet mitigation

Once the cluster is updated, remove the eBPF DaemonSet mitigation by removing the daemon set and the pods. You can either delete the daemonset first and then related namespace, or you can remove the namespace. Removing the namespace will remove the pods as well.

$ oc delete project cve-2026-31431-mitigation-ebpf

$ oc get –all -n cve-2026-31431-mitigation-ebpf

Root Cause

A flaw was found in the Linux kernel's algif_aead cryptographic algorithm interface. An incorrect 'in-place operation' was introduced, where the source and destination data mappings were different. This could lead to unexpected behavior or data integrity issues during cryptographic operations, potentially impacting the reliability of encrypted communications.

Red Hat is developing a fix for the CVE that will be released in z-streams for OpenShift 4.16, 4.18, 4.19, 4.20, and 4.21 through internal bug trackers.
Until the fix is released, a mitigation described in the *Resolution" section can be applied to the cluster to disable the affected component.

Red Hat Engineering has completed standard e2e tests on non-FIPS, FIPS, and IPSec clusters and showed no known side effects of the kernel argument mitigation. Workloads that rely on AF_ALG socket access to AEAD kernel crypto APIs will be blocked, this is not common and there are no known uses of this functionality in out of the box OpenShift code. However user workloads may rely on this, still, that's not common.

Diagnostic Steps

Check if the kernel running on the nodes already includes the fix for the CVE-2026-31431:

$ oc debug node/<NODENAME>
# chroot /host
# rpm -q kernel --changelog | grep CVE-2026-31431
- crypto: algif_aead - snapshot IV for async AEAD requests (Herbert Xu) [RHEL-172197] {CVE-2026-31431}
- crypto: algif_aead - Fix minimum RX size check for decryption (Herbert Xu) [RHEL-172197] {CVE-2026-31431}
- crypto: authencesn - reject short ahash digests during instance creation (Herbert Xu) [RHEL-172197] {CVE-2026-31431}
- crypto: authencesn - Fix src offset when decrypting in-place (Herbert Xu) [RHEL-172197] {CVE-2026-31431}
- crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption (Herbert Xu) [RHEL-172197] {CVE-2026-31431}
- crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl (Herbert Xu) [RHEL-172197] {CVE-2026-31431}
- crypto: algif_aead - Revert to operating out-of-place (Herbert Xu) [RHEL-172197] {CVE-2026-31431}
- crypto: af-alg - fix NULL pointer dereference in scatterwalk (Herbert Xu) [RHEL-172197] {CVE-2026-31431}

If the output is similar to the above, the fix is already included in the kernel used by the node, and not required to check the following Diagnostic Steps.

Check that algif_aead is built into the kernel by running:

$ oc debug node/<NODENAME>
# chroot /host
# cat /lib/modules/$(uname -r)/modules.builtin | grep algif_aead

Check that the ALG protocol is present on the node:

$ oc debug node/<NODENAME>
# chroot /host
# cat /proc/net/protocols | grep ALG

Check if the AF_ALG socket is in use in any node:

$ oc debug node/<NODENAME>
# chroot /host
# lsof -w | grep ALG

SBR

Shift Security

Product(s)

Red Hat OpenShift Container Platform

Components

Category

Secure

Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.