GitHub project details zero-downtime eBPF and seccomp defenses for active Linux kernel zero-days

A GitHub repository that reached Hacker News' front page documents a defense-in-depth playbook for holding production Linux hosts together during an active kernel zero-day window — without rebooting anything. The approach combines eBPF syscall telemetry, seccomp gating, kernel module disarmament, and container user namespaces to compensate for three concurrently exploited vulnerabilities.

The problem: a weeks-long patch gap

According to the project's documentation, the three flaws — CVE-2025-39964 in the AF_ALG crypto netlink interface, CVE-2026-53266 in netfilter's ebtables bridging code, and CVE-2025-39682 in kernel TLS — were all listed in CISA's Known Exploited Vulnerabilities catalog. That starts an operational clock: the README estimates that seven to 21 days typically pass between public weaponization of a kernel bug and the availability of tested, signed binary packages from enterprise distributions such as Ubuntu HWE, Debian and RHEL. Waiting passively exposes clusters to exploitation, while emergency kernel upgrades and reboots risk outages — a particular tension for Kubernetes fleets.

Three vulnerabilities, three defense modes

The framework classifies each mitigation by security property rather than by subsystem. CVE-2026-53266, described as an arithmetic overflow in bridge ARP table rewrite rules, gets prevention: the vulnerable ebtables modules are evicted from kernel memory and blocked from reloading. CVE-2025-39964, an integer truncation in netlink crypto socket allocation that the documentation rates as high severity for local privilege escalation and container breakout, gets detection and gating: eBPF rules watch for socket() calls using domain 38 (AF_ALG), and seccomp can synchronously reject them. CVE-2025-39682, a zero-length record processing flaw in kTLS, gets detection by tracing setsockopt() calls at both the TCP_ULP attachment phase and the SOL_TLS configuration phase.

Evict, then seal

One operational nuance the project stresses: a modprobe.d override such as pointing an install command at /bin/true only blocks future load attempts. If bridge networking — Docker or a legacy CNI — loaded ebtables earlier in the host's lifecycle, the vulnerable code remains resident in kernel RAM. Disarmament therefore needs two steps: unload the resident modules with modprobe -r, then write the loader overrides and blacklist entries that prevent a reload. The README includes verification commands showing that explicit modprobe attempts afterwards leave no ebtables modules in memory.

eBPF detection and the kTLS two-phase trap

Detection runs through Falco's eBPF engine, which hooks the sys_enter tracepoint and pushes events into a ring buffer with what the documentation describes as sub-millisecond alerting, without modifying kernel control flow. Where synchronous rejection is required, the project points to an eBPF LSM probe or a seccomp profile that drops the syscall before execution instead.

The kTLS rules correct a subtle mistake the author says is easy to make. Enabling kernel TLS on a TCP connection happens in two phases: first the ULP is attached with setsockopt(fd, SOL_TCP, TCP_ULP, "tls"), then keys are configured via SOL_TLS. A rule filtering only on SOL_TLS misses the attachment phase, so the Falco rules in the repository match both.

The README also records a stability fix from the field: on Linux 7.0+ HWE kernels, Falco's userspace inspector reportedly fails to parse openat parameters and throws exceptions, so the DaemonSet excludes openat from its base syscall set to avoid crash loops.

Reaction pipeline and containment

Alerts flow from Falco and Falcosidekick through a forwarder daemon onto a NATS message bus, which feeds an automated bouncer — CrowdSec or nftables drop rules — plus a tamper-evident audit ledger built from SHA-256 hash chains replicated across nodes. For containment, the design pairs the detection layers with containerd v2.2.4 user namespace remapping, so a container's UID 0 maps to a high unprivileged host UID (4050714624 in the example), bounding what a compromised container root can do on the host.

Why it matters

This is a compensating-controls playbook, not a substitute for patching: nothing here fixes the underlying bugs, and it is a single self-published case study rather than a vendor-supported product. Its value for ops teams is as a concrete, adaptable template for the window when a kernel zero-day is being exploited but signed packages do not yet exist. The details that make it credible are the ones usually learned the hard way — blacklist files do not unload modules already in memory, kTLS filters must cover both setsockopt phases, and the detection tooling itself can break on newer kernels. For anyone running Kubernetes or large Linux fleets, the layered structure is the takeaway: disarm what you can, detect and gate what you cannot, and contain whatever still gets through.