CVE Mitigations

CSM treats CVEs as a three-layer problem:

1. Operator-driven hardening via csm harden ... - applies the right preventive control for the host (modprobe blacklist, seccomp drop-ins, sysctl tweaks).
2. Continuous enforcement by the daemon - re-asserts the control on every startup and as a periodic check, so a package upgrade or manual modprobe does not silently undo the mitigation.
3. Live detection - auditd/BPF listeners flag exploit signatures the moment they fire, even on hosts where the kernel itself cannot be patched.

The hardening audit detects what the host actually has (kernel build, KernelCare livepatches, seccomp coverage) and refuses to claim protection it cannot deliver. Run csm harden with no arguments for the full list of available mitigations on the current host.

Active mitigations

CVE-2026-31431 - “Copy Fail” (Linux kernel AF_ALG)

Two operator paths depending on whether AF_ALG is loadable on the kernel:

• csm harden --copy-fail - writes /etc/modprobe.d/csm-copy-fail-mitigation.conf blacklisting algif_aead and af_alg, then unloads them. Refuses on kernels where AF_ALG is built in (typical cPanel / CloudLinux 8), since the blacklist would have no effect there.
• csm harden --copy-fail-seccomp - writes systemd RestrictAddressFamilies=~AF_ALG drop-ins for the units that spawn untrusted code: LiteSpeed, Apache/Nginx, every PHP-FPM pool, cron, mail. The right path on built-in-AF_ALG kernels.

The audit recognises KernelCare CVE-2026-31431 livepatches via kcarectl --patch-info and reports pass only when the host is genuinely mitigated (module blacklisted, seccomp drop-ins applied, or KernelCare livepatch active).

Live detection and BPF blocking

BPF-tagged builds (make BPF=1 or go build -tags bpf) load an LSM socket_create program on kernels with BPF LSM and ringbuf support. That program refuses socket(AF_ALG, ...) from non-root UIDs before the AF_ALG socket is allocated, returns EPERM, emits a ringbuf event, and feeds the existing Critical af_alg_socket_use finding path. UID 0 keeps AF_ALG access for system crypto users. There are no UID-range or alert-only BPF tunables today; use detection.af_alg_backend to select auditd or none if a host needs to avoid kernel-side refusal.

Default builds, BPF-tagged builds on unsupported kernels, and hosts forced to detection.af_alg_backend: auditd keep the audit-log listener. The audit path catches non-system AF_ALG socket attempts at Critical within about 500 ms but cannot stop the syscall before it reaches the kernel. Hosts that are not exploitable skip the live listener.

If CSM attempts the AF_ALG BPF path and cannot start it, it emits a bpf_unavailable finding. The finding says whether the audit fallback is active or no live fallback is available.

Auto-response

• auto_response.copy_fail_kill_process: true - SIGKILL the offending process when the live listener fires. Default off (alert-only).
• auto_response.disable_enforce_af_alg: true - suspend the periodic re-assertion of the module blacklist without removing the hardening marker. For triage only.

The daemon self-heals its auditd rule file on startup if it has drifted from the embedded copy, closing the upgrade gap where a new binary shipped without re-running postinstall would leave detection silently inactive.

Configuration knob

• detection.af_alg_backend - auto (default) | bpf | auditd | none. auditd is the kill switch for a misbehaving BPF-tagged release. bpf is strict mode (no fallback). none disables the live listener entirely.

The csm_af_alg_backend{kind="bpf-lsm"|"auditd-tail"|"none"} Prometheus gauge surfaces which backend the coordinator selected at startup, so dashboards can see the active path without parsing logs.

BPF validation

On a BPF LSM host with a BPF-tagged CSM build:

1. Set detection.af_alg_backend: bpf for strict validation, or leave it as auto and confirm BPF was selected.

2. Start the daemon and check metrics:

   curl -k -H "Authorization: Bearer $CSM_TOKEN" https://127.0.0.1:9443/metrics \
     | grep -E 'csm_af_alg_backend|csm_bpf_backend'
   

   Expected selected series:

   csm_af_alg_backend{kind="bpf-lsm"} 1
   csm_bpf_backend{feature="af_alg",kind="bpf"} 1
   

3. As a non-root user, attempt an AF_ALG socket:

   sudo -u nobody python3 - <<'PY'
   import errno
   import socket
   import sys
   
   try:
       socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0)
   except OSError as exc:
       print(exc.errno)
       sys.exit(0 if exc.errno == errno.EPERM else 1)
   
   raise SystemExit("AF_ALG socket unexpectedly succeeded")
   PY
   

4. Confirm the command prints 1 (EPERM) and CSM emits a Critical af_alg_socket_use finding. The finding details should say the call was refused by the BPF LSM program.

CVE-2026-41940 - cPanel/WHM auth-bypass

Detection in the access-log path:

• Non-infra WHM login attempts surface at Warning (suppressible alongside other cPanel-login alerts) so an operator can see brute force traffic against the bypass surface.
• The tokenless WHM-script request the published exploit uses for cache promotion surfaces at Critical, always-on, and feeds auto-block.

No operator hardening command is required. The host fix is to apply the cPanel patched build. CSM provides the detection layer for windows where patching has not yet rolled out.

Future CVEs

New mitigations land here as they ship. The bar is:

• The host can be measurably hardened (modprobe / seccomp / sysctl / config), and/or
• An exploit-signature detector can fire reliably without false positives.

CVEs that are purely “patch the package”, with no preventive control we can apply and no signature we can detect, do not get a CSM mitigation; the right answer is the vendor patch. The daemon’s package-integrity check (rpm -V / debsums) covers the “did the operator actually apply the patch” question.