cve-af-alg-block

Runtime mitigation for the "Copy-Fail" Linux kernel vulnerability (https://xint.io/blog/copy-fail-linux-distributions) that disables the AF_ALG socket family without rebooting and without waiting for a vendor kernel update.

A SystemTap script hooks alg_create() (the .create callback for AF_ALG in crypto/af_alg.c) and forces its return to -EPERM, so every socket(AF_ALG, ...) fails. That denies the entire algif_* family — aead, hash, skcipher, rng, compress — at the only entry point they share. cPanel/WHM and the standard service stack do not use AF_ALG, so blocking it has no functional impact on a typical web/hosting host.

Why this exists

• No KernelCare patch for Copy-Fail at the time of writing. Until KernelCare or your distro vendor ships one, the only fix is a new kernel — i.e. a reboot.
• Even after KernelCare ships a patch, rebootless application requires an active KernelCare subscription. Hosts without one still need a kernel package update + reboot.
• Not every host can reboot on demand — shared hosting, cPanel boxes, customer hardware, hosts with maintenance windows weeks out. This is a stopgap until the host is on a fixed kernel.

What's in this repo

File	Purpose
cve-af-alg-block.stp	SystemTap source. Probes alg_create().return and overrides its return register with -EPERM.
cve-af-alg-block.service	systemd unit; runs staprun against the prebuilt .ko on every boot.
install-cve-af-alg-block.sh	Installer / management wrapper.
test-cve-af-alg-block.py	Verifier — tries every algif_* variant; each must fail with EPERM.

How it works

stap -p4 compiles the .stp into a kernel module pinned to the running kernel. staprun loads it. From then on, every return from alg_create() is rewritten to -EPERM before control returns to the socket-creation path, so socket(AF_ALG, ...) always fails. Because the hook is on the family .create callback (not on individual algif_* registrations), new algorithms can't bypass it.

The .ko is not portable between kernels — rebuild after every kernel upgrade.

Installer

Run on the target host as root with the four source files in the same directory.

Command	What it does
./install-cve-af-alg-block.sh (or install)	Copy sources into place, check deps, compile .ko, enable + start the service, run the test harness.
install-deps	yum install SystemTap + kernel-devel + kernel-debuginfo for the running kernel.
build	Recompile .ko for the current uname -r. Run after a kernel upgrade.
test	Run only the verifier.
status	Service state, lsmod check, artefact listing.
uninstall	Stop service, unload module, remove all files.

Files installed:

/etc/cve-af-alg/cve-af-alg-block.stp          0600   (kept on host for rebuilds)
/var/lib/cve-af-alg/cve_af_alg_block.ko       0600   (kernel-pinned)
/usr/local/sbin/cve-af-alg-block.sh           0755   (mgmt wrapper = installer)
/usr/local/sbin/test-cve-af-alg-block.py      0755
/etc/systemd/system/cve-af-alg-block.service  0644

After install, cve-af-alg-block.sh status|build|test|uninstall works from anywhere. If check_deps fails, the installer leaves sources in place and exits without starting the service — run install-deps, then build, then systemctl enable --now cve-af-alg-block.service.

After a kernel upgrade:

./install-cve-af-alg-block.sh install-deps   # devel/debuginfo for new kernel
./install-cve-af-alg-block.sh build          # rebuild .ko

Testing the block

Bundled harness — exits 0 if all variants are blocked, 1 if any opened a socket, 2 on harness error:

cve-af-alg-block.sh test

Expected:

[BLOCKED]      aead / gcm(aes) — socket() denied: EPERM
[BLOCKED]      hash / sha256   — socket() denied: EPERM
[BLOCKED]  skcipher / cbc(aes) — socket() denied: EPERM
[BLOCKED]       rng / stdrng   — socket() denied: EPERM
RESULT: all AF_ALG variants blocked — mitigation working.

One-liner — PermissionError means blocked, silent return means not blocked:

python3 -c 'import socket; socket.socket(38, socket.SOCK_SEQPACKET, 0)'

Status check — service should be active (running) and lsmod must show cve_af_alg_block:

cve-af-alg-block.sh status

If the unit is active but lsmod doesn't show the module, the .ko failed to load (usually built for a different kernel than the one currently running). Rerun build, then systemctl restart cve-af-alg-block.service.

Caveats

• Requires SystemTap + matching kernel-devel and kernel-debuginfo (install-deps handles this on RHEL-family).
• Runtime instrumentation, not a permanent kernel patch — treat as a stopgap until the host runs a fixed kernel.
• The .ko is kernel-pinned; rebuild on every kernel update.
• Audit before broad deployment if anything on the host actually uses AF_ALG (uncommon outside of specialised crypto workloads).

Uninstall once the host has a real fix booted (patched kernel or confirmed KernelCare patch loaded):

cve-af-alg-block.sh uninstall