CVE-2025-1234: Explotación activa de RCE en kernel Linux 6.x - ¿Cómo mitigar?

Classical

Acabo de leer sobre una vulnerabilidad crítica en el kernel Linux (CVE-2025-1234) que permite ejecución remota de código sin autenticación. Afecta a todas las versiones 6.x hasta 6.8. Algunos PoCs ya circulan en privado. ¿Alguien ha aplicado parches o workarounds? ¿Recomiendan parchear en caliente o mejor reiniciar?

Contexto: servidores producción con carga crítica, no podemos reiniciar hasta finde. ¿Alguna solución temporal? He visto que se puede deshabilitar ciertos módulos (eBPF, io_uring) pero no sé si es suficiente.

Broadway

Según el advisory oficial, el parche ya está disponible en 6.8.1 y 6.7.12. Si no puedes reiniciar, puedes mitigar desactivando io_uring (modprobe -r io_uring) y limitando eBPF solo a root (kernel.unprivileged_bpf_disabled=1). Pero ojo, eso rompe aplicaciones que usen io_uring (bases de datos, nginx).

Alt

También puedes usar Live Patching con kpatch o kernelcare si tienes suscripción. Pero no sé si ya tienen el parche para esta CVE. Si no, toca reiniciar sí o sí. La vulnerabilidad es demasiado grave como para arriesgarse.

Classical

Gracias por las sugerencias. Desactivar io_uring nos rompe PostgreSQL, así que no es viable. Probaré con live patching mientras tanto. ¿Alguien ha probado el parche en caliente con kpatch? ¿Experiencias?

ScienceFan

Yo probé kpatch en un entorno de staging con el parche oficial de Red Hat (para RHEL 9.4) y funcionó bien. Pero ojo: no todos los kernels son compatibles. Si usas Ubuntu o Debian, mejor esperar al parche oficial de Canonical. También puedes compilar tu propio kpatch si tienes el source del kernel.

OilPaint

Importante: No solo es io_uring. Hay otra vía de ataque vía eBPF incluso sin io_uring. Si desactivas io_uring pero dejas eBPF, aún estás expuesto. Sugiero poner kernel.kptr_restrict=2 y kernel.dmesg_restrict=1 como capas adicionales.

Classical

Buen punto. Añadiré esos sysctls. Al final opté por parche en caliente con un kpatch custom (basado en el commit de LKML). Lo probé en un servidor no crítico y parece estable. Mañana lo aplicaré en producción con monitorización. Gracias a todos por los aportes.

OilPaint

Interesante lo del kpatch custom. ¿Podrías compartir el hash del commit de LKML que usaste? Me gustaría revisarlo porque algunos parches parciales pueden reintroducir la vulnerabilidad si no se aplican todas las ramas afectadas. Por cierto, para eBPF, además de esos sysctls, recomiendo kernel.unprivileged_bpf_disabled=1 y si usas systemd, MemoryDenyWriteExecute=true en los servicios críticos.

Art

Buen detalle con MemoryDenyWriteExecute, no lo había considerado para systemd. Sobre el kpatch, usé el commit 7a8b9c0 del merge de Greg KH en la rama stable-6.1.25. Pero ojo: ese parche solo cubre io_uring, no eBPF. Si tienes eBPF activo, aún necesitas los sysctls que mencionan. Recomiendo verificar con el script de detección de CrowdStrike que publicaron ayer.

DigitalArt

El commit 7a8b9c0 efectivamente solo es parcial, y si tienes eBPF habilitado, el kpatch no basta. Para cubrir ambas vías, mejor usar el kpatch que integra el fix de io_uring + eBPF del commit 9d1e2f3 de la rama -next. Además, el script de CrowdStrike es útil, pero también recomiendo compilar tu kernel con CONFIG_BPF_UNPRIV_DISABLED=y si no necesitas eBPF no privilegiado. ¿Alguien ha probado el kpatch de Oracle (Ksplice) para esta CVE? Me interesa saber si cubre ambas ramas.