Livepatch, parchear el núcleo sin reiniciar

Un parche en vivo carga en el núcleo en ejecución un fragmento que sustituye la función con el fallo. El núcleo sigue siendo el mismo: uname -r muestra el mismo número que antes del parche. Por eso un escáner que solo compara ese número con el corregido seguirá marcando el hallazgo aunque el fallo esté tapado en memoria.

La conclusión no es ignorar al escáner ni creerle sin más: se comprueba el estado del parche en vivo del servidor y se anota como evidencia de mitigación, con el hallazgo todavía abierto hasta decidir cómo se cierra.

El parche en vivo no corrige todo. Los servicios de este tipo se centran en ciertas correcciones del núcleo (las de mayor gravedad) y algunas no se pueden aplicar en memoria. Su estado lo dice explícitamente: lista las correcciones aplicadas y, aparte, las que no cubre. Esas últimas solo se resuelven con un núcleo nuevo y un reinicio.

Abre estado-mdt-app02.txt y lee los dos apartados.

Tener el cliente de parche en vivo instalado no es tener el servicio. Si no está registrado, o la suscripción venció, no aplica nada. El estado exportado lo distingue: «activo», «instalado pero inactivo», «no instalado». Un inventario que solo mira si el paquete existe da una falsa tranquilidad.

Compara los tres archivos de estado y los resultados de hallazgos-nucleo.txt.

El parche en vivo es una medida de contención: gana tiempo, no sustituye el reinicio. La política de reinicios de Molinos del Tabacal lo dice con claridad. Una corrección que el parche no cubre mantiene al servidor expuesto, así que el acuerdo con el dueño es una fecha de reinicio dentro de la próxima ventana, no «ya está parcheado».

Lee politica-de-reinicios.txt y decide qué se registra en el hallazgo de mdt-app02 para CVE-2099-2203.