cve-2026-31431 mitigation using ftrace

The ebpf solutions around for mitigating cve-2026-31431 require lsm=bpf at boot time, which is usually not set by default. For OracleLinux this was enabled by default in UEKr7u3 and in UEKr8u1 after December 2025.

To check whether or not you can use ebpf-lsm to mitigate copyfail, check /sys/kernel/security/lsm for bpf.

Since a couple of our machines are running a slightly older kernel (due to $reasons) I looked for other ways to mitigate this security issue, either by blocking AF_ALG/AEAD or AF_ALG at once.

I thought of a kernel module intercepting __sock_create and blocking AF_ALG or intercepting aead_bind and blocking all requests. The idea was to do that with ftrace.

To compile the modules, try the following:

git clone this_repository
cd this_repository
make

For Oracle Linux with UEK make sure to install and use the correct packages before running make:

. /etc/os-release
releasever=${VERSION/.*}
uek=7 # or 8, whatever you use
dnf -y --enablerepo=ol${releasever}_UEKR${uek} install kernel-uek-devel make gcc kernel-headers
# you might need one of the following:
# for oel9/uekr8
. /opt/rh/gcc-toolset-14/enable
# for oel8/uekr7
. /opt/rh/gcc-toolset-11/enable

Then load the module:

# block AF_ALG at once
insmod /path/to/af_alg_block.ko
# or only block AF_ALG/AEAD
insmod /path/to/af_alg_aead_block.ko

Now all requests for AF_ALG or all AEAD-bindings (depending on which module you loaded) should be blocked, all attempts should be logged.

DISCLAIMER

I'm no kernel developer. I studied the ftrace documentation and built this module by trial&error until all AF_ALG requests were blocked, without affecting other address families.

I tested that on some machines and for me this looks stable. I give no guarantee it works for you, other attack vectors might circumvent this module, or the module does not render your machine unstable.

However, it's a quick fix to fill the time until the machines can finally be rebooted.