
Herramienta de detección y mitigación de vulnerabilidades para los bugs Copy Fail y Dirty Frag (CVE-2026-31431, CVE-2026-43284, CVE-2026-43500)
Audita un host Linux remoto a través de SSH en busca de las vulnerabilidades de módulos del kernel Copy Fail y Dirty Frag y, opcionalmente, aplica mitigaciones:
| CVE | Nombre | Módulos afectados |
|---|---|---|
| CVE-2026-31431 | Copy Fail | algif_aead |
| CVE-2026-43284 | Dirty Frag (IPsec) | esp4, esp6, ipcomp4, ipcomp6, xfrm_user |
| CVE-2026-43500 | Dirty Frag (RxRPC) | rxrpc, kafs |
Para cada módulo afectado, vcheck informa si está cargado actualmente, integrado en el kernel en ejecución, si tiene rastros pasados en los registros del kernel, si hay sockets AF_ALG activos (solo Copy Fail) y si ya está en la lista negra en /etc/modprobe.d/.
Con -fix, vcheck informa el estado inicial, escribe un fragmento cve-XXXX-XXXXX-disable.conf para cualquier módulo que aún no esté en la lista negra, luego vuelve a ejecutar las comprobaciones e informa el estado final. Con -fix -unload, vcheck también intenta descargar los módulos afectados que estaban cargados antes de la corrección, luego usa el análisis final para verificar si aún están cargados. Con -fix -rebuild-initramfs, vcheck reconstruye el initramfs para el kernel actualmente en ejecución (solamente) después de escribir un fragmento, de modo que la lista negra quede incorporada en la imagen de arranque siguiente. Las entradas de kernel anteriores conservan su initramfs original como respaldo.
-fix solo después de una ejecución de solo verificaciónEjecute siempre vcheck sin -fix primero. Lea el informe y confirme que los módulos afectados son seguros de deshabilitar en este host antes de volver a ejecutar con -fix. Deshabilitar módulos del kernel de los que dependen cargas de trabajo legítimas puede afectar a los usuarios y romper aplicaciones.
En particular:
-fix como seguro solo cuando ninguno de los módulos afectados esté actualmente cargado, es decir, cada módulo se reporte como mitigado o módulo no en lista negra (sin líneas VULNERABLE o en lista negra pero actualmente cargado). Un módulo cargado casi siempre significa que algo en el host lo está usando activamente; verifique eso antes de ponerlo en la lista negra.esp4, esp6, ipcomp4, ipcomp6, xfrm_user) son necesarios para cualquier implementación de IPsec/strongSwan/WireGuard-over-IPsec/IKE. Los módulos ipcomp4/ipcomp6 implementan la compresión de carga útil IPComp y pueden ser auto-negociados como parte de una SA IPsec incluso cuando no están configurados explícitamente. No ponga en la lista negra ninguno de ellos en una puerta de enlace VPN, un punto final IPsec, o en cualquier lugar donde ip xfrm policy devuelva reglas. Tenga en cuenta que el módulo del framework xfrm_algo está intencionalmente no en esta lista — según la guía de los proveedores (Red Hat, Ubuntu, AWS), bloquear los módulos de protocolo ESP e IPComp más la interfaz de configuración netlink xfrm_user es suficiente, y poner en la lista negra xfrm_algo rompería cualquier otra transformación xfrm sin beneficio adicional.rxrpc, kafs) son necesarios para cualquier host que monte sistemas de archivos AFS. Deshabilitarlos romperá esos montajes en el próximo arranque.algif_aead expone la criptografía del kernel a través de la familia de sockets AF_ALG. Rara vez es usado directamente por código de aplicación, pero verifique listando los sockets activos (ss -p --af-alg) y comprobando los consumidores en espacio de usuario antes de ponerlo en la lista negra.Los fragmentos de lista negra que escribe vcheck solo surten efecto en el momento de carga del módulo (típicamente en el próximo arranque, o modprobe -r <módulo> mientras el sistema está inactivo). Un módulo que ya está cargado seguirá funcionando incluso después de -fix — vcheck reportará esto como en lista negra pero actualmente cargado; ejecute 'modprobe -r' o reinicie. Pasar -unload con -fix le pide a vcheck que ejecute modprobe -r para los módulos afectados cargados después de escribir los fragmentos de lista negra. Úselo solo cuando haya confirmado que los módulos son seguros de eliminar del kernel en ejecución.
Pasar -rebuild-initramfs con -fix regenera el initramfs solo para el kernel actualmente en ejecución (update-initramfs -u -k $(uname -r) en Debian/Ubuntu, dracut -f --kver $(uname -r) en RHEL/Fedora). Otros kernels instalados mantienen su initramfs existente intacto, por lo que si algo sale mal después de reiniciar, puede seleccionar una entrada de kernel anterior desde el menú de arranque y recuperarse. Las futuras instalaciones de kernel reconstruyen su propio initramfs a partir del estado actual de /etc/modprobe.d/, por lo que la lista negra se propaga automáticamente sin necesidad de volver a ejecutar vcheck. Si no está presente ni update-initramfs ni dracut (por ejemplo, Arch, Alpine, imágenes inmutables), vcheck advierte y continúa — reconstruya manualmente con la herramienta de la distribución antes de reiniciar.
La reconstrucción puede tardar varios minutos (especialmente dracut en hosts con muchos controladores), lo que excedería el tiempo de espera de diagnóstico -command-timeout. Se ejecuta bajo su propio -initramfs-timeout (por defecto 10m) para que la reconstrucción tenga el tiempo que necesita mientras que las comprobaciones rápidas mantienen su presupuesto ajustado. Aumente -initramfs-timeout para hardware lento, o pase 0 para deshabilitar el tiempo de espera por completo. Durante los comandos remotos de larga duración, vcheck envía solicitudes de keepalive SSH cada 30s por defecto para evitar que los temporizadores de inactividad NAT/cortafuegos corten la conexión. Ajuste esto con -ssh-keepalive, o pase 0 para deshabilitarlo.
Homebrew (macOS):
brew install --cask krisiasty/tap/vcheck
Binarios precompilados para Linux, macOS y Windows están publicados en la página de versiones.
Desde el código fuente (requiere Go 1.26+):
go install github.com/krisiasty/vcheck@latest
vcheck -host HOST [flags]