Tres CVEs Linux kernel activas: defensa sin reboot con eBPF

Tres vulnerabilidades Linux en producción y un plazo de 72 horas

El 18 de septiembre, CISA añadió tres vulnerabilidades del kernel Linux a su catálogo Known Exploited Vulnerabilities (KEV), lo que activó un plazo de remediación de 72 horas para agencias federales bajo la directiva BOD 26-04. Los CVEs son CVE-2025-39682 (CVSS 7.1 según NVD, 9.8 según SecurityWeek), CVE-2025-39964 (CVSS 7.8 según CNA) y CVE-2026-53266 (CVSS 8.8), todos con evidencia confirmada de explotación activa.

El problema operativo para equipos SRE es conocido: el espacio entre la weaponización pública de un zero-day y la disponibilidad de paquetes kernel firmados por las distribuciones enterprise suele ser de 7 a 21 días. Esperar pasivamente expone los clusters a exploits; un kernel upgrade prematuro o un reboot de emergencia arriesga caídas operativas.

Un repositorio publicado por el equipo Sovereign Systems & Security Architecture documenta precisamente cómo aplicar controles compensatorios en capas —usando eBPF, SECCOMP, modprobe y user namespaces— para defender clusters Kubernetes sin necesidad de reboot.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Qué hace cada CVE y por qué importa

CVE-2025-39682 vive en net/tls/tls_sw.c, la implementación software de TLS en el kernel. El bug se activa cuando un atacante procesa un registro TLS de longitud cero en el modo zero-copy, corrompiendo el contador de referencias del anchor buffer. El resultado: use-after-free al cerrar el socket, con potencial de kernel panic o memory disclosure. Afecta al kernel Linux 6.0 a 6.16.3 y los release candidates 6.17-rc1/rc2. Investigadores de STAR Labs publicaron un PoC con confirmación KASAN.

CVE-2026-53266 reside en el target ebt_snat del bridge netfilter. Cuando un paquete ARP se procesa sobre un socket buffer no lineal, el kernel escribe el SHA directamente sobre la página de respaldo sin verificar skb_ensure_writable(). Esto permite out-of-bounds write sobre memoria del kernel принадлежащую a objetos no relacionados, vector para LPE. Publicada el 25 de junio de 2026.

CVE-2025-39964 afecta la interfaz AF_ALG (Crypto API userspace). Es una race condition que permite que dos writers concurrentes intercalen datos en el mismo socket, dejando el estado interno inconsistente. El scoring está disputado (NVD: 3.3, Red Hat: 5.5, CNA: 7.8), pero el listado en KEV es la señal operativa: la explotación está confirmada independientemente del CVSS.

El framework de defensa: tres CVEs, tres capas

El repositorio estructura las defensas por propiedad de seguridad —Prevention, Runtime Detection, Containment— y no por subsistema. Eso evita el error común de tratar cada CVE como si requiriera la misma técnica.

Capa 1 — Disarmament de módulos (Prevención para CVE-2026-53266)

Un error frecuente al usar /etc/modprobe.d/ es creer que install /bin/true basta. Solo bloquea cargas futuras: si Docker o un CNI legacy cargó ebtables antes en el ciclo de vida del host, el código vulnerable sigue activo en RAM kernel.

La técnica correcta es una secuencia de dos pasos:

Eviction: descargar los módulos residentes con modprobe -r.
Sealing: configurar el override del loader (install /bin/true) y blacklist para impedir recargas.

El script evict-and-harden.sh del repositorio automatiza esto y valida con lsmod | grep ebt que el módulo ya no esté residente.

Capa 2 — Detección eBPF + gating SECCOMP (CVE-2025-39964 y CVE-2025-39682)

Para los CVEs que no admiten disarmament limpio, el patrón es observar primero, bloquear si es necesario:

Asíncrono (EDR con eBPF): Falco engancha sys_enter vía ring buffers CO-RE, evaluando socket(AF_ALG, …) (domain 38) y setsockopt(SOL_TCP, TCP_ULP=31) o setsockopt(SOL_TLS=282). Overhead sub-milisegundo, sin modificar el flujo de control del kernel.
Síncrono (bloqueo inline): donde se requiere rechazo con -EACCES antes de la syscall, un probe eBPF LSM o un perfil SECCOMP con SCMP_ACT_ERRNO corta la ejecución. El repo incluye seccomp-block-af-alg.json listo para aplicar.

Detalle clave para el CVE de kTLS: el ataque tiene dos fases. Filtrar solo por SOL_TLS=282 pierde la fase 1 (adjuntar el ULP). La regla Falco del repositorio evalúa ambas: (SOL_TCP=6 AND TCP_ULP=31) OR (SOL_TLS=282).

Sobre kernels Linux 7.0+ HWE, el inspector userspace de Falco (sinsp) puede encontrar mismatches de parsing en openat. El repo recomienda excluir openat de las syscalls base (custom_set: ['!openat']) para evitar crash loops del DaemonSet.

Capa 3 — User Namespaces + cadena hash criptográfica (Containment)

Aunque eBPF detecte la syscall, si el exploit alcanza el kernel antes del corte, queremos que la escalada quede contenida. Con containerd v2.2.4 y Kubernetes CRI v1.30 configurando hostUsers: false, el UID 0 del contenedor se remapea a un UID host no privilegiado (ej. 4050714624). Una escalada Netlink/socket que consiga root queda acotada al namespace no-root.

Para auditoría, los eventos viajan por un pipeline Falco → Falcosidekick (:2801) → forwarder (:9876) → NATS bus (sovereign.security.alert), y un ledger con SHA-256 chaining registra cada alerta con el hash del registro anterior. La replicación cross-node a 192.0.2.52 impide que un host comprometido reescriba su historial. El repo validó 386.213 registros sin tampering.

Qué significa esto para tu startup

Si corres Kubernetes en producción sobre Linux, este caso es la plantilla operativa que necesitás tener a mano antes del próximo CVE KEV. Tres acciones concretas:

Audita qué módulos están cargados en cada nodo AHORA. Un script simple (lsmod | grep ebt) te dice si ebtables está residente. Si lo está y no lo necesitás, podés evictarlo y aplicar el override del loader en menos de cinco minutos, sin reboot. Para equipos que usan CNI modernos (Cilium, Calico eBPF), es probable que ebtables no sea necesario.
Despliega Falco con reglas de CVEs activos como parte del baseline. El repo incluye helm/falco-rules-kernel-cve.yaml listo para helm install. Cuando llegue el próximo CVE KEV, añadir la regla nueva toma minutos, no días. Mantené el DaemonSet estable excluyendo syscalls problemáticas como openat si estás en kernel 7.0+ HWE.
Habilita user namespaces en workloads multi-tenant. hostUsers: false con containerd 2.2+ rompe la cadena de escalada trivial de container root a host root. Validá con cat /proc/$(pgrep -f workload)/uid_map que el mapeo esté activo.

Métricas que respaldan la urgencia

El Verizon DBIR 2026 documenta que solo el 26% de las vulnerabilidades KEV fueron completamente remediadas en 2025, frente al 38% del año anterior, con una mediana de 43 días para remediación total. El plazo de 72 horas de BOD 26-04 es estructuralmente agresivo contra esa realidad; el objetivo no es cumplimiento del 100%, sino garantizar que las exposiciones de mayor riesgo se traten como emergencias operativas. En el lado del kernel patching, opciones como kpatch (Red Hat) o Canonical Livepatch pueden aplicar fixes sin reboot, pero su cobertura depende del calendario de cada vendor — verificá en el catálogo de live-patches antes de asumir que podés diferir el reboot.