PATTERN Cited by 1 source

bpf-lsm allowlist hook denial¶

bpf-lsm allowlist hook denial is the pattern of gating a vulnerable kernel code path by attaching an eBPF program to the relevant Linux Security Module (LSM) hook and denying the hook for every caller except an explicit allow-list of known-legitimate binaries. Rather than unloading the vulnerable kernel module (coarse, breaks legitimate callers, not always possible) or waiting for a patched kernel to roll through the reboot pipeline (slow, LTS backport may be late), the pattern provides a runtime, reboot-free, surgical mitigation at LSM-hook granularity. Canonical wiki instance from the 2026-05-07 Copy Fail response post, where Cloudflare denied the socket_bind LSM hook for AF_ALG with an allow-list of legitimate binaries.

Structure¶

                       ┌───────────────────────┐
  Caller attempts      │  LSM hook fires       │
  operation that       │  (socket_bind,        │
  triggers LSM hook    │   file_open, etc.)    │
  ──────────────────▶  │                       │
                       │  bpf-lsm program      │
                       │  runs in kernel       │
                       └───────────┬───────────┘
                                   │
                     ┌─────────────┼─────────────┐
                     ▼             ▼             ▼
              Not the target    AF_ALG     AF_ALG +
              resource (e.g.    socket +   allow-listed
              non-AF_ALG)       caller     caller
                     │          not on     on list
                     │          list         │
                     ▼             │         ▼
                  ALLOW            ▼       ALLOW
              (no change)       DENY
                              (EPERM)

When it fits¶

The vulnerable kernel code path is reachable via a well-defined LSM hook — the kernel's security module framework already fires hooks for most security-relevant operations (socket creation, file access, process execution, mmap, module load, etc.).
The subsystem has a finite known set of legitimate callers that can be enumerated into an allow-list.
The scale is too large for whole-fleet reboot within the incident window — the LTS backport gap or the reboot cycle makes a patched kernel too slow.
Whole-module removal would break legitimate callers (as in the Copy Fail 2026-04-29 staging failure before the Copy Fail mitigation was refined).
eBPF + BPF-LSM is supported by the kernel on the fleet.

When it doesn't fit¶

Vulnerability not reachable via an LSM hook. Some kernel bugs are in code paths no LSM hook fires against — the BPF-LSM framework can't gate what it can't see.
Legitimate callers can't be enumerated. If the allow-list has no stable definition (e.g. every user's shell legitimately hits the subsystem), the allow-list degenerates to allow-all and the mitigation has no effect.
Fleet doesn't support BPF-LSM. Older kernels (pre-5.7 generally) or kernels without CONFIG_BPF_LSM can't load bpf-lsm programs; the pattern requires LSM + BPF + verifier.
Performance cost exceeds tolerance. A bpf-lsm program that runs on a very hot hook (e.g. file_open) can add measurable overhead; measure first on representative traffic.

Structural properties¶

Hook-level selectivity. The program targets one specific LSM hook, not the whole subsystem. For Copy Fail the hook is socket_bind; other hooks and other subsystems compose without interference.
Default-deny posture for the gated operation. The program denies the operation for every caller that isn't on the allow-list. Structurally stronger than "deny known-bad".
Allow-list typically identity-based. Binary path is the common identity; can be strengthened with UID, cgroup, process lineage, or signed-binary verification per threat model.
No reboot required. Attachment is runtime. Detachment (rollback) is also runtime. Entire rollout + rollback fits inside the incident window.
Verifier-gated. The eBPF verifier proves termination, memory safety, bounded complexity before loading — structural safety primitive for the runtime kernel extension.
Composable with whole-fleet reboot. Runs in parallel with the scheduled patched-kernel rollout. bpf-lsm covers the window; patched kernel closes it. At final state, every machine is protected by either a patched kernel or a bpf-lsm program denying the vulnerable code path to non-allow-listed binaries.

Canonical instance: Copy Fail socket_bind denial (2026-04-30)¶

The bpf-lsm program runs on every socket_bind call:

If socket_family != AF_ALG → allow. Cheap — ~all production traffic.
If socket_family == AF_ALG → check calling binary's path against the allow-list of legitimate AF_ALG users (as validated empirically in the visibility phase via ebpf_exporter).
If binary on allow-list → allow the bind.
Otherwise → deny with EPERM.

Net effect: the algif_aead kernel module stays loaded — the one internal legitimate service continues to work — but any other attempt to bind an AF_ALG socket returns PermissionError: [Errno 1] Operation not permitted. This blocks the Copy Fail exploit at step 2 ("Create an AF_ALG socket, bind() to authencesn(hmac(sha256),cbc(aes))").

End-to-end verification on a previously-vulnerable test node confirmed the exploit no longer works.

Failure modes¶

Allow-list too narrow. Legitimate-but-unknown caller gets denied, causing internal outage. Mitigated by running measurement first.
Allow-list too broad. Binary-path-based allow-list is bypassable if an attacker controls a process that renames itself or executes from an allow-listed path. Mitigated by stronger identity primitives (UID, cgroup, signed binaries).
Hook not fine-grained enough. If the LSM hook fires too early or too late in the operation's lifecycle, the denial may not cover all attack variants. Choose the hook that fires on the specific operation the exploit needs.
Per-CVE engineering cost. Every new CVE requires a fresh eBPF program with CVE-specific hook + allow-list logic. This is one of Cloudflare's self-disclosed follow-ups: "faster deployments, better playbooks" for bpf-lsm.

Sibling patterns¶

Whole-module modprobe blacklist — coarser; breaks legitimate callers. Copy Fail's rejected first-attempt (2026-04-29 staging failure).
Patched kernel rollout — permanent fix but slower, bounded by reboot pipeline cadence. Runs in parallel with the bpf-lsm allow-list pattern.
seccomp-bpf container composition — per- process syscall allow-list at a different altitude (namespace boundary). Complementary, not replacement.
Visibility-before-enforcement rollout — how the allow-list gets validated empirically before enforcement lands.

Seen in¶

2026-05-07 — Cloudflare Copy Fail response. Canonical wiki first-class page. socket_bind LSM hook; AF_ALG socket family; allow-list of legitimate AF_ALG users validated via ebpf_exporter visibility phase. Exploit attempts see EPERM; one legitimate internal service continues to work. End-to-end verification on a previously- vulnerable test node confirmed the exploit no longer works after the program is loaded. (Source: sources/2026-05-07-cloudflare-copy-fail-linux-vulnerability-response)