La vulnerabilidad COW de Linux en «pedit», detrás de un nuevo exploit de root

¿Buscas medidas de mitigación? Ve directamente a ↓

La versión resumida

Qué: Una vulnerabilidad de escalada de privilegios locales en Linux denominada «pedit COW» (CVE-2026-46331), consistente en una escritura sin comprobación de límites en la acción de control de tráfico «act_pedit» del núcleo. La función tcf_pedit_act() calcula su rango de «copia al escribir» (COW) una sola vez antes de editar las cabeceras de los paquetes, no tiene en cuenta el desplazamiento que añaden las claves tipadas en tiempo de ejecución y acaba escribiendo en una página que nunca se ha convertido en privada —una COW parcial que acaba en la caché de páginas compartidas—.

Impacto: Una prueba de concepto pública y verificada por el autor proporciona a cualquier usuario local sin privilegios una vía directa para obtener un shell de root en los sistemas afectados en los que se pueda acceder a la acción «act_pedit» y existan espacios de nombres de usuario sin privilegios. La prueba de concepto corrompe la imagen almacenada en caché de «setuid-root /bin/su» y permite acceder directamente a root. Red Hat califica esta vulnerabilidad como «Importante».

Estado: Se trata de una vulnerabilidad de «N días», no de una sorpresa del mismo día. La corrección se desarrolló de forma abierta en la lista netdev como un parche rutinario para la corrupción de datos (asunto: «net/sched: corrección de COW parcial de pedit que provoca la corrupción de la caché de páginas»), sin CVE ni marco de seguridad. El CNA de kernel.org asignó el CVE-2026-46331 en el momento de la incorporación, el 16 de junio de 2026 —semanas después de que los detalles explotables ya fueran públicos— y el 17 de junio se publicó una prueba de concepto (PoC) explotable. Las ramas Mainline y Stable ya están corregidas; Red Hat y AlmaLinux han publicado errata.

Gravedad: vector de ataque local, complejidad baja una vez cumplidos los requisitos previos, sin interacción del usuario, corrupción determinista de la caché de páginas que permite obtener privilegios de root y código de explotación público operativo. Clase de fallo: escritura fuera de límites que provoca corrupción de memoria y escalada de privilegios local. El CVSS aún no se había concretado en el momento de la publicación; la calificación «Importante» de Red Hat es la que debe tenerse en cuenta a la hora de actuar.

Hazlo ahora mismo: instala un kernel corregido por el proveedor, si existe (RHEL 8/9/10, AlmaLinux 8, Debian 13), y reinicia el sistema. El parche de KernelCare que no requiere reinicio aún se encuentra en fase de pruebas y todavía no se ha incorporado a ningún canal de actualizaciones, así que no esperes a que esté disponible. Hasta que puedas aplicar el parche, impide que se cargue act_pedit si no utilizas reglas tc pedit y/o restringe los espacios de nombres de los usuarios sin privilegios. A continuación se indican los comandos y las ventajas e inconvenientes.

La versión larga

CVE-2026-46331 es otro fallo de corrupción de la caché de páginas de Linux que convierte un error de escritura del núcleo en una vía práctica para obtener privilegios de root a nivel local. Se encuentra en el subsistema de control de tráfico, concretamente en la acción de edición de paquetes «act_pedit» que utiliza tc para reescribir los bytes de la cabecera de los paquetes en tránsito.

Lo inquietante no es solo el error, sino cómo salió a la luz.

El parche de origen se debatió públicamente como una corrección de corrupción de datos, sin CVE y sin un enfoque de seguridad evidente. El CVE llegó más tarde, en el momento de la fusión, el 16 de junio, y al día siguiente se publicó una prueba de concepto (PoC) explotable. Esto convierte a pedit COW en un «N-day» en el sentido que importa a los defensores: el detalle técnico explotable era visible en una lista de correo pública antes de que la mayoría de los equipos dispusieran de un CVE, una regla de escáner, un aviso del proveedor o un proceso de parche asociado al mismo.

No detectamos este fallo a través de nuestro propio sistema de seguimiento. Nos llegó a través de una escalación de un cliente: nunca apareció en oss-security, y el canal CNA del núcleo no figura actualmente en nuestra lista de seguimiento. Esa laguna es en sí misma una lección sobre los fallos del núcleo que se corrigen primero y para los que el CVE se asigna después, y es una de las razones por las que existe esta entrada.

¿Me afecta esto?

Se considerará que un host está expuesto si se cumplen todas las condiciones siguientes:

• El núcleo contiene la ruta de código vulnerable de act_pedit.
• El módulo act_pedit está cargado o se puede cargar automáticamente cuando sea necesario.
• Los espacios de nombres de usuario sin privilegios están habilitados, lo que proporciona al atacante el privilegio CAP_NET_ADMIN a nivel local del espacio de nombres que necesita el exploit.
• Un usuario local sin privilegios o con privilegios parciales puede ejecutar código en el equipo.

act_pedit se carga automáticamente en cuanto se configura una acción «pedit tc», por lo que un lsmod vacío no significa que todo esté en orden, como podría parecer. Comprueba las tres condiciones:

# Is the module loaded right now?
lsmod | grep -w act_pedit

# Can it be loaded on demand?
modinfo act_pedit 2>/dev/null | head -n 1

# Are unprivileged user namespaces available?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

También puedes comprobar si realmente utilizas la acción: el comando «tc actions list action pedit» devuelve un resultado vacío en los hosts que hoy no ejecutan reglas de pedit. Un resultado vacío no garantiza la seguridad —un atacante que pueda insertar una regla desde dentro de un espacio de nombres seguirá pudiendo acceder a la ruta de código—, pero te indica si es seguro aplicar la medida de mitigación recomendada de la lista negra de módulos.

En RHEL y Debian, el usuario sin privilegios está abierto por defecto. En Ubuntu está restringido por el kernel mediante kernel.apparmor_restrict_unprivileged_userns / _unconfined, pero esa restricción es una medida de refuerzo de la seguridad, no una corrección del kernel: el PoC la elude con un truco de aa-exec en la versión 24.04. Ubuntu 26.04 muestra el mensaje «FAIL» ante el PoC por el mismo motivo relacionado con AppArmor, mientras que el kernel subyacente sigue siendo vulnerable.

¿Qué es pedit COW?

«pedit» es la abreviatura de «packet editor» (editor de paquetes), una acción de control de tráfico que permite a los administradores reescribir los campos de las cabeceras de los paquetes a medida que estos pasan por los filtros y acciones de tc configurados. La función vulnerable es tcf_pedit_act(), situada en el archivo net/sched/act_pedit.c.

Pertenece a la misma familia que «Dirty Pipe», «Copy Fail» y «Dirty Frag»: una rutina del núcleo escribe en una página de la que no es propietaria exclusiva, y la escritura acaba en una entrada de la caché de páginas que respalda un archivo en el disco. Lo nuevo aquí es el punto de entrada. En lugar de una ruta rápida de cifrado o una ruta de descifrado sin copia, el desencadenante es una acción de edición de paquetes que un proceso sin privilegios puede configurar desde dentro de un espacio de nombres de usuario.

A grandes rasgos, el error se debe a que el rango de paquetes modificables se calcula demasiado pronto. Antes de modificar los datos de los paquetes, el núcleo llama a skb_ensure_writable() para que los bytes de destino sean privados. La función tcf_pedit_act() calculaba ese rango una sola vez, antes del bucle sobre las claves de edición, utilizando una referencia precalculada denominada tcfp_off_max_hint. La indicación no tenía en cuenta el desplazamiento de la cabecera en tiempo de ejecución que añaden las claves tipadas: dichas claves resuelven sus desplazamientos respecto a las cabeceras L2/L3/L4 en el momento de la ejecución, por lo que el desplazamiento real de escritura solo se conoce una vez que el bucle está en marcha. Por lo tanto, parte del destino nunca se marca como privada. Se trata de una copia parcial en escritura (COW), y escribir en la región no sujeta a COW supone una escritura fuera de límites y entre páginas.

Dado que el SKB puede hacer referencia a páginas sin copia (zero-copy) obtenidas mediante `sendfile`, esa escritura fuera de límites puede acabar en la memoria compartida de la caché de páginas que respalda un archivo real. El núcleo cree que ha hecho que la memoria del paquete sea segura para su modificación; en realidad, la escritura posterior se extiende más allá de la región que realmente ha privatizado.

Cómo funciona realmente la vulnerabilidad

El PoC público (sgkdev/packet_edit_meme) encadena cuatro elementos comunes —la acción `act_pedit`, los búferes de socket que pueden hacer referencia a páginas de copia cero, los espacios de nombres de usuario sin privilegios y la caché de páginas— y no requiere ni modelado del montón ni ventana de carrera.

1. Espacio de nombres y capacidad. Desde un espacio de nombres de usuario sin privilegios, el atacante obtiene la capacidad CAP_NET_ADMIN local al espacio de nombres, lo cual le basta para configurar acciones de control del tráfico dentro del espacio de nombres que controla.
2. Enlace de control de tráfico. Configuran una acción «pedit» con claves tipadas cuyo desplazamiento en tiempo de ejecución queda fuera del rango que tcf_pedit_act() ha marcado como escribible, lo que desencadena la escritura COW parcial.
3. Ataque dirigido a la caché de páginas. Al introducir referencias a archivos «zero-copy» en la pila de red, pretenden provocar una escritura fuera de límites en la imagen ELF almacenada en caché del comando /bin/su con permisos setuid-root.
4. Carga útil. Sobrescriben el punto de entrada almacenado en caché con un código shell equivalente a setgid(0), setuid(0) y execve(“/bin/sh”).
5. Root. Salen del espacio de nombres y ejecutan «su». La caché de páginas compartida sirve la imagen maliciosa y el código de shell se ejecuta como root.

El binario almacenado en el disco nunca cambia. La corrupción solo se produce en la caché de páginas, razón por la cual los análisis de hash de archivos y el análisis forense del disco pueden dar resultados normales, aunque ya haya un shell de root abierto. El único requisito previo importante son los espacios de nombres de usuario sin privilegios con CAP_NET_ADMIN, que están abiertos por defecto en RHEL y Debian, y restringidos en Ubuntu.

Qué cambia con la corrección del desarrollador

La corrección combinada (asunto: «net/sched: act_pedit: ampliar el rango de skb grabable por tecla») reestructura la ruta COW para que el rango grabable siga el desplazamiento real:

• Traslada la función skb_ensure_writable() al interior del bucle por clave, donde se conoce el desplazamiento de escritura real.
• Añade una comprobación de desbordamiento en las operaciones aritméticas con el desplazamiento y protege la función `offset_valid()` contra el valor `INT_MIN`, en el que la negación no está definida.
• En el caso de los desplazamientos negativos —como las modificaciones de la cabecera de Ethernet en la entrada—, utiliza skb_cow() para aplicar COW al margen de la cabecera.
• Linealiza los skbs que transportan fragmentos compartidos al principio, por lo que una página «zero-copy» no puede corromperse de forma silenciosa.

Se trata de una modificación independiente que afecta a una sola función. El parche «rebootless» de KernelCare es una adaptación fiel de esta corrección del código original, en lugar de un equivalente conservador de kpatch: reconstruye la ruta COW dentro de tcf_pedit_act() con la misma lógica de skb_ensure_writable() / skb_cow() por clave y los mismos controles de desplazamiento.

Por qué era fácil pasar por alto este error

«pedit-cow» nunca se presentó a los desarrolladores como una emergencia específica. Parecía una corrección de corrupción de datos de red, y se tramó en el árbol de versiones como tal.

Esto es importante porque la mayoría de los flujos de trabajo de parches supervisan los feeds de CVE, los avisos de los proveedores, oss-security y las actualizaciones de los escáneres. En este caso concreto, las implicaciones de seguridad no se hicieron evidentes hasta más tarde: primero se detectó el parche, luego llegó el CVE en la fase de fusión y, al cabo de un día, apareció la prueba de concepto (PoC). En el caso de los errores del núcleo de esta clase, la estrategia de «corregir primero, CVE después» abre una ventana de oportunidad en la que los atacantes y los investigadores especializados comprenden la posibilidad de explotación antes incluso de que los procesos habituales de aplicación de parches de las empresas registren el problema.

Conclusión práctica: hay que considerar que las correcciones públicas del núcleo relacionadas con la corrupción de la caché de páginas, el COW parcial, las escrituras sin copia y la gestión del rango de SKB grabable pueden tener implicaciones de seguridad antes de que aparezca un CVE o un PoC.

¿A quién afecta?

La vulnerabilidad se reduce a tres aspectos: si se puede cargar «act_pedit», si se permite el acceso a usuarios sin privilegios y si tu distribución incluye un núcleo corregido.

Se ha confirmado que el público puede explotar esta vulnerabilidad mediante una prueba de concepto (verificada por el autor, sin privilegios de root):

• RHEL 10.0 en 6.12.0-228.el10: no se necesita ningún indicador; los usuarios están abiertos por defecto
• Debian 13 trixie en 6.12.90+deb13.1: no se necesita ninguna opción
• Ubuntu 24.04.4 en 6.17.0-22: requiere la opción «–ubuntu aa-exec userns» para el bypass

Ubuntu 26.04 (7.0.0-14) devuelve «FAIL», pero eso se debe a que el refuerzo de seguridad de AppArmor para los usuarios está funcionando correctamente, no a que se haya corregido el núcleo. El núcleo subyacente sigue siendo vulnerable.

Solución proporcionada por el fabricante (instalar el núcleo parcheado y reiniciar el sistema):

• RHEL 10 – RHSA-2026:27288
• RHEL 9 – RHSA-2026:27789
• RHEL 8 – RHSA-2026:27353; la versión recompilada para AlmaLinux 8 es ALSA-2026:27353 (publicada el 22 de junio). RHSA-2026:27355 es la variante 8.8 EUS/TUS.
• Debian 13 trixie – DSA-6355-1 (publicado el 21 de junio)

Además de la rama principal y los backports estables.

Afectados, pero sin solución oficial por parte del proveedor todavía: los servidores en los que, a día de hoy, la única opción es aplicar medidas de mitigación provisionales, y en los que la cobertura de los parches sin necesidad de reiniciar será fundamental una vez que se publiquen:

• Debian 11 y 12
• Ubuntu Bionic hasta Noble (la versión 24.04.4 es un objetivo confirmado para la prueba de concepto)

No se ven afectados o siguen abiertos:

• RHEL 7 / CentOS 7: no se ven afectados.
• Oracle UEK 6 y UEK 7: estado «abierto» en nuestro hilo de desarrollo.

Actúa ya

La opción más segura es proteger inmediatamente el núcleo en ejecución. Existen tres medidas prácticas, por orden de preferencia.

1. Parche o parche sin necesidad de reiniciar

Instala el kernel corregido por el proveedor, si existe, y reinicia el sistema tan pronto como sea operativamente posible. Da prioridad a los hosts en los que se ejecuta código parcialmente fiable: nodos de Kubernetes, ejecutores de CI/CD, alojamiento compartido, sistemas de desarrollo y compilación, plataformas multitenant y hosts de contenedores que aceptan cargas de trabajo no fiables.

Los parches de KernelCare para CVE-2026-46331 que no requieren reinicio se encuentran en fase de desarrollo activo y se están probando en comparación con la corrección del proyecto original. Según el último estado de cobertura, aún no se ha publicado nada en los canales de prueba, principal ni ePortal. Una vez que se publique una compilación, compruébala:

kcarectl --patch-info | grep -i 'CVE-2026-46331'
kcarectl --info | grep kpatch-build-time      # build dated on or after the release

2. Desactiva act_pedit si no lo utilizas

act_pedit se carga automáticamente en cuanto se configura una acción «pedit tc». Si no ejecutas ninguna regla «tc pedit» —como ocurre en la mayoría de los servidores—, impide que se cargue.

El boletín de Red Hat (RHSB-2026-008) recomienda utilizar una lista negra durante el arranque:

echo 'blacklist act_pedit' > /etc/modprobe.d/blacklist-act-pedit.conf

Una lista negra solo impide la carga automática al arrancar el sistema. Dado que act_pedit puede cargarse automáticamente bajo demanda en el momento en que una regla lo referencia, la forma más fiable de bloquearlo es mediante una configuración de instalación que redirija el módulo a /bin/true:

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

A continuación, comprueba si está cargado y descárgalo solo si ninguna regla de tráfico activa depende de él:

lsmod | grep -w act_pedit && sudo rmmod act_pedit
lsmod | grep -w act_pedit || echo "act_pedit not loaded"

Para revertir los cambios, elimina el archivo:

sudo rm /etc/modprobe.d/disable-act_pedit.conf

Ámbito de aplicación: cualquier configuración de control de tráfico que utilice «action pedit» no se cargará mientras el bloqueo esté activo. Algunas configuraciones de contenedores/CNI y de calidad de servicio (QoS) dependen de ello, por lo que no se debe aplicar esta medida en los hosts que necesiten reglas «tc pedit». Compruébalo con el comando «tc actions list action pedit» antes de implementarlo de forma generalizada.

3. Restringir los espacios de nombres de los usuarios sin privilegios

El exploit necesita un espacio de nombres de usuario sin privilegios para obtener el derecho CAP_NET_ADMIN a nivel local de dicho espacio de nombres. El cierre de los espacios de nombres de usuario sin privilegios interrumpe la cadena pública, independientemente del estado del módulo.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

En Ubuntu, en cambio, puedes reforzar los controles existentes de AppArmor (kernel.apparmor_restrict_unprivileged_userns / _unconfined), que es lo que bloquea el PoC en la versión 26.04 de forma predeterminada.

Nota sobre compatibilidad: los espacios de nombres de usuario sin privilegios son necesarios para los entornos de ejecución de contenedores sin root, varios entornos de pruebas de CI, la función unshare(1) sin privilegios, los navegadores en entornos aislados y Flatpak. Son aceptables en cargas de trabajo reforzadas o de alojamiento, pero pueden causar problemas en los hosts de desarrollo y de contenedores. Prueba antes de una implementación generalizada.

Momento decisivo

Si el servidor no ejecuta ninguna regla «tc pedit» → bloquear «act_pedit»; esta es la modificación más restrictiva. Si necesita «pedit», pero no contenedores sin root ni «unprivileged unshare» → restringir los usuarios en su lugar. Si necesita ambas cosas → la única solución real es aplicar un parche o un parche sin reinicio; aislar la ejecución local no fiable hasta entonces.

Parche sin reinicio de KernelCare

Estado a fecha de 23 de junio de 2026, a las 18:30 UTC: en fase de pruebas activas bajo el ticket principal KCARE-27230. Aún no hay ninguna versión disponible en los canales de prueba, principal ni ePortal. El trabajo específico para cada distribución se gestiona en los tickets KCARE-27167 (EL10), KCARE-27223 (EL9), KCARE-27159 (EL8) y KCARE-27204 (Debian 13).

Una vez que una compilación se incorpore al canal de pruebas, aplícala con:

kcarectl --update --prefix test

Una vez validado, se incluirá en la próxima ejecución programada, o bien puedes recuperarlo cuando lo necesites:

kcarectl --update

Comprueba:

kcarectl --patch-info | grep -i 'CVE-2026-46331'

Detección

No existe ninguna firma fiable posterior a la compromisión para «pedit-cow». La corrupción se encuentra en la caché de páginas; el binario del disco permanece intacto, y las pruebas desaparecen en cuanto se eliminan las páginas almacenadas en caché o se reinicia el sistema. Las comprobaciones de integridad de los archivos son un indicador poco fiable en este caso.

Las señales de comportamiento que vale la pena buscar:

• El módulo act_pedit se carga de forma inesperada en los hosts que no ejecutan la edición de paquetes de control de tráfico.
• Actividad inusual de tc por parte de usuarios o procesos que normalmente nunca configuran la red.
• Creación de espacios de nombres de usuario sin privilegios poco antes de la ejecución del binario setuid.
• El uso de «su», «sudo» o la ejecución de comandos en el shell tras una acción de control del tráfico sin motivo legítimo.

Supervisar la ejecución de tc y la carga de módulos:

auditctl -w /sbin/tc -p x -k tc_exec
auditctl -w /usr/sbin/tc -p x -k tc_exec
grep act_pedit /proc/modules

Si sospechas que se está produciendo un abuso, vacía la caché de la página para forzar la recarga de los bytes originales desde el disco:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Considéralo una medida de contención, no de corrección. Si un atacante ya ha obtenido privilegios de root, la expulsión no elimina la persistencia que haya establecido posteriormente. Cualquier host en el que un usuario local no de confianza haya tenido acceso a la línea de comandos durante el periodo de exposición debe considerarse potencialmente comprometido.

¿Por qué siguen apareciendo errores como «pedit-cow»?

«pedit-cow», «Dirty Pipe», «Copy Fail» y «Dirty Frag» difieren en los detalles, pero comparten un patrón común: una ruta rápida orientada al rendimiento que parte de una suposición errónea sobre si es seguro escribir en una página. En cada caso, una escritura llegó a una página que el núcleo creía que le pertenecía, y la caché de páginas se vio afectada porque, por diseño, es compartida: todos los lectores de un archivo ven la misma página física, por lo que una sola escritura errónea en ella puede hacerse visible para el código con privilegios que lee bytes ejecutables.

Estos errores son peligrosos precisamente porque convierten la «corrupción de la memoria local» en algo útil. Un atacante no tiene que eludir los permisos de los archivos ni modificar nada en el disco. Solo tiene que corromper la copia almacenada en caché el tiempo suficiente para que el código con privilegios pueda leerla o ejecutarla.

La solución más profunda no consiste en «dejar de optimizar». Consiste en garantizar con mayor firmeza la propiedad de las páginas en todas las rutas de gestión de memoria del núcleo, una tarea laboriosa, ya que afecta a las partes del núcleo más sensibles al rendimiento. pedit-cow no será el último fallo de esta familia. Esto también pone de manifiesto por qué cada vez resulta más difícil dar una respuesta el mismo día: una vulnerabilidad puede pasar de ser un parche de aspecto corriente a convertirse en un CVE y, posteriormente, en un exploit público de root antes de que muchas organizaciones tengan una visión clara de la situación operativa.

Lista de verificación de medidas correctoras priorizadas

1. Parche. Instala el kernel corregido por el proveedor (RHEL 8/9/10, AlmaLinux 8, Debian 13) y reinicia el sistema. No esperes al parche de KernelCare que no requiere reinicio, ya que aún no está disponible en ningún canal de actualización.
2. Aplica medidas de mitigación cuando no sea posible aplicar un parche. Bloquea «act_pedit» si no ejecutas reglas «tc pedit», o restringe a los usuarios sin privilegios si te lo puedes permitir.
3. Audita el acceso local. Comprueba quién tiene acceso a la línea de comandos en servidores compartidos, ejecutores de CI/CD, servidores de compilación y sistemas multitenant. Revoca los permisos que no sean necesarios durante ese periodo.
4. Busca. Aplica los algoritmos heurísticos de detección a la ventana de exposición, empezando por la publicación en la lista de correo de finales de mayo en adelante.
5. Reinicia el sistema tras aplicar los parches. De este modo se eliminan las páginas en caché que puedan estar corruptas, junto con el núcleo antiguo.

Referencias

• NVD – CVE-2026-46331: https://nvd.nist.gov/vuln/detail/CVE-2026-46331
• Entrada en CVE.org: CVE-2026-46331
• Aviso de GitHub GHSA-cr2w-747q-47qc
• Red Hat RHSB-2026-008 – Escalada de privilegios en el control de tráfico, y la página de CVE de Red Hat
• Erratas del proveedor: RHSA-2026:27288 (RHEL 10), RHSA-2026:27789 (RHEL 9), RHSA-2026:27353 (RHEL 8 = AlmaLinux ALSA-2026:27353; RHSA-2026:27355 es la variante 8.8 EUS/TUS), DSA-6355-1 (Debian 13)
• Sistema de seguimiento de seguridad de Debian – CVE-2026-46331
• Demostración pública de concepto (Massimiliano Oldani, 17 de junio de 2026): https://github.com/sgkdev/packet_edit_meme
• Hilo de netdev: servidores espejo de LKML v2 y v3; raíz del hilo en Spinics
• Stable fix commits (git.kernel.org/stable/c/<hash>): 899ee91156e5, 2bec122b9fb9, 3dee9d0c198f, b198ed4e5258
• Seguimiento de KernelCare: caso general KCARE-27230; parche sin reinicio CL gerrit 256818; por distribución KCARE-27167 / 27223 / 27159 / 27204

Aplica parches a cualquier kernel sin necesidad de reiniciar. Si aún no eres usuario de KernelCare, ahora es un buen momento para descubrir cómo la aplicación de parches sin reinicio protege los sistemas Linux críticos sin necesidad de ventanas de mantenimiento de emergencia ni tiempos de inactividad.

Más información sobre KernelCare aquí →