PwnEscape: el fallo IPv4 de Linux que filtró memoria del host

Lo más interesante del fallo Crítico del desafío Sandbox de 1.000.000 $ de Vercel no es que un invitado llegara al host. Es cómo: no venciendo al hipervisor, sino entregando al kernel del host un paquete cuyos propios metadatos de checksum reescribieron una cabecera que el kernel ya había validado. El investigador Paulos Yibelo, de PWNAI Research, lo bautizó PwnEscape, y se entiende mejor como una variante nueva de una clase de fallo antigua: una carrera time-of-check/time-of-use, pero sobre metadatos de paquetes en lugar de sobre un archivo o un puntero.

La vieja suposición: una cabecera validada sigue validada

Cuando la pila de red de Linux recibe o construye un paquete IP, valida la cabecera: la versión es IPv4, el campo IHL (Internet Header Length) indica cuántas palabras de 32 bits ocupa la cabecera, las opciones están acotadas y las longitudes son coherentes. Todo lo que viene después (enrutamiento, fragmentación, copia de bytes al cable) confía en esa cabecera validada. El contrato implícito es sencillo: una vez revisada la cabecera, no cambia por debajo.

Los kernels modernos rompen ese contrato por una buena razón: el rendimiento. Calcular checksums es caro, así que la pila lo aplaza. Con CHECKSUM_PARTIAL, el kernel registra dónde habrá que escribir el checksum mediante metadatos de descarga, sobre todo csum_start (el desplazamiento en bytes donde empieza el cálculo) y csum_offset (dónde cae el resultado), y completa el checksum más tarde, a menudo justo antes de que el paquete salga. El paso de completado escribe de vuelta en el búfer del paquete. Si esa escritura puede apuntarse a bytes que el validador ya aprobó, tienes una ventana time-of-check/time-of-use (TOCTOU), y lo que se disputa no es un archivo, sino la propia cabecera del paquete.

El mecanismo: el completado del checksum reescribe el nibble IHL

Esta es la cadena, en términos llanos:

1. Un invitado envía un paquete con metadatos de descarga de checksum elegidos por el atacante. El kernel trata esos metadatos como la descripción de dónde terminar el checksum.
2. La cabecera IPv4 se valida: en ese instante IHL vale el normal 0x45 (versión 4, longitud de cabecera de 5 palabras = 20 bytes).
3. Más tarde se ejecuta el completado diferido del checksum, que escribe su resultado en el búfer en el desplazamiento al que apuntaban los metadatos. Si se diseña para que la escritura caiga sobre el primer byte de la cabecera, cambia ese nibble a 0x4f: IHL pasa a indicar 15 palabras = 60 bytes.
4. Nada vuelve a validar. La etapa siguiente, el fragmentador IP / copia de cabecera, cree que la cabecera mide 60 bytes y copia 60 bytes, aunque solo existían 20 bytes de paquete real.
5. Los 40 bytes extra más allá de la cabecera real se tratan ahora como opciones IP, y la copia arrastra unos 32 bytes de memoria adyacente del host al campo de opciones IP del paquete saliente.

El paquete que el invitado emite a la red lleva ahora un trozo de memoria del kernel del host que nunca debió ver. Repítelo y tienes una primitiva de divulgación continua de memoria del host: una fuga que controlas desde dentro del sandbox y lees del cable.

Por qué es un «desajuste de coordenadas» entre capas

La confusión de fondo es que dos partes de la pila razonan sobre el paquete en sistemas de coordenadas distintos. El validador razona sobre la cabecera L3 (IP): versión, IHL, opciones. La maquinaria de descarga de checksum razona en desplazamientos de búfer crudos, definidos en torno a la vista L2/de tramado del skb: csum_start es solo «tantos bytes dentro del búfer». Se supone que ambas vistas son coherentes, pero nada obligaba al desplazamiento de descarga a respetar los límites que le importaban al validador L3. Cuando un invitado controla los metadatos, controla un desplazamiento en un sistema de coordenadas que escribe en un campo que importa en el otro, y la invariante de cabecera validada muere sin hacer ruido. Esa es la forma general que conviene recordar: una escritura diferida, guiada por metadatos, que cae dentro de datos ya validados y relevantes para la seguridad.

Qué está confirmado y qué es una demostración de laboratorio

Mantén ambas cosas separadas a propósito: la fuga es la consecuencia confirmada en el mundo real; el cuelgue y el escape son lo que el mismo fallo permitió en un laboratorio controlado. Un análisis previo sobre este tema confundió justo esta distinción al presentar un escape de laboratorio como un hecho en producción, así que aquí vamos con cuidado.

Dónde encaja PwnEscape en el desafío de 1 M$

PwnEscape fue el único hallazgo Crítico del desafío de Vercel. Según la publicación de hallazgos del 14 de octubre de 2026 de Vercel, el desafío (en marcha desde agosto de 2026) recibió 1.285 reportes, pagó 242.000 $ y contabilizó 57 hallazgos válidos, de los cuales uno fue Crítico. Fue este. Esa proporción ya es una lección de seguridad: un incentivo de siete cifras contra una frontera endurecida produjo exactamente un fallo que cruzó la línea invitado→host, y entró por el kernel, no por el hipervisor.

Parchea ya: la corrección y los backports

La corrección upstream es el commit 6785011f8b16, «ipv4: validate checksum_start before completing checksum», escrito por el desarrollador del kernel Michael S. Tsirkin e integrado por Jakub Kicinski el 8 de octubre de 2026. Se ha portado a los kernels estables: 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 y 7.2. Los mantenedores describen el cambio como defensa en profundidad, con una validación más completa de los metadatos de checksum todavía por llegar, así que es un mínimo, no la última palabra.

Hay un CVE pendiente y todavía no hay ningún identificador CVE autorizado; cita el commit (6785011f8b16) como identificador hasta que salga el CVE. Parchea los kernels de tus hosts a una versión que incluya el backport y sigue el aviso de tu distribución para el mapeo al CVE. Cuando se publique, podrás puntuar su impacto ambiental en tu entorno con la Calculadora CVSS → (3 ejecuciones gratis con una cuenta gratuita).

Qué debería sacar un líder de seguridad del mecanismo

• ☐ Parchea el kernel del host: ese es el control. El hipervisor hizo su trabajo; el componente vulnerable era el kernel de Linux que corre en cada host. Prioriza el parcheo del kernel de toda la flota de hosts a una versión con el commit 6785011f8b16, y pregunta a tus proveedores con qué rapidez parchean los kernels de los hosts, no solo los hipervisores.
• ☐ Trata el kernel compartido del host como la verdadera frontera entre inquilinos. En el cómputo multiinquilino y de sandbox, un defecto del kernel alcanzable desde el invitado cruza la línea de la que depende toda tu historia de aislamiento, aunque el muro de la VM aguante. Compara cómo exponen esa superficie distintas pilas con nuestra comparación de aislamiento de hipervisores →.
• ☐ Endurece el host del hipervisor, no te limites a confiar en él. Reduce lo que puede alcanzar un invitado que escapa o filtra: kernels de host mínimos, funciones expuestas al invitado acotadas, controles de salida y ningún secreto crítico residente en hosts compartidos. Recorre el checklist de endurecimiento de KVM → para endurecer tus hosts de hipervisor frente a exactamente esta clase de fallo del kernel alcanzable desde el invitado.
• ☐ Asume la primitiva de fuga antes que el escape. Una divulgación continua de memoria del host ya es un resultado grave: secretos, claves y datos de inquilinos vecinos pueden salir en paquetes mucho antes de que nadie demuestre ejecución de código. Diseña para que una fuga sea sobrevivible: claves de cifrado en manos del inquilino, mínimo privilegio y segmentación que limite el radio de impacto de la coubicación.
• ☐ Vigila la clase más amplia de TOCTOU sobre metadatos. La lección va más allá de IPv4: cualquier escritura diferida e influida por el atacante sobre datos ya validados es candidata al mismo fallo. Vuelve a validar los campos relevantes para la seguridad después de cualquier paso que pueda modificarlos.

Créditos

Investigador: Paulos Yibelo, PWNAI Research (pwn.ai); análisis técnico en pwn.ai/blog/pwnescape. Fuente primaria independiente: Vercel, «Findings from the $1M Vercel Sandbox challenge». La corrección es el commit upstream de Linux 6785011f8b16.

La conclusión

PwnEscape recuerda que el aislamiento es una pila de fronteras, y que la más débil que se pueda alcanzar decide tu exposición. Aquí el hipervisor aguantó y el propio kernel del host, al procesar un paquete cuyos metadatos de checksum reescribieron una cabecera ya validada, no. La consecuencia confirmada es una fuga de memoria del host en producción real; el escape es una demostración de laboratorio, no una afirmación sobre producción. Parchea los kernels de los hosts con la corrección portada, trata el kernel compartido del host como la frontera que de verdad importa y endurece el host para que un fallo del kernel alcanzable desde el invitado sea sobrevivible en lugar de fatal.

Relacionado: los hallazgos completos del Vercel Sandbox y el encuadre hipervisor frente a kernel. Compara diseños de aislamiento con la comparación de hipervisores, endurece tus hosts con el checklist de endurecimiento de KVM, puntúa el CVE cuando salga con la calculadora CVSS y mantente al día en PlayCISO AI Labs.