El kernel Linux arrastra desde hace años un fallo en su capa de TLS que se ha resuelto ahora bajo el identificador CVE-2026-23240. Es un use-after-free provocado por una condición de carrera, con una puntuación CVSS de 9.8 sobre 10 según kernel.org. Dicho de otro modo: gravedad crítica.
Qué pasa exactamente
El subsistema TLS del kernel (kTLS) descarga el cifrado de las conexiones TLS dentro del propio núcleo, sin pasar por una librería de espacio de usuario. Parte de ese trabajo de transmisión se hace de forma diferida mediante un delayed work llamado tx_work_handler(), que vive en net/tls/tls_sw.c.
Cuando se cierra el socket, tls_sk_proto_close() llama a tls_sw_cancel_work_tx(), que a su vez usa cancel_delayed_work_sync() para cancelar ese trabajo pendiente antes de liberar el objeto TLS. El problema es que esa cancelación no impide que el trabajo vuelva a programarse después. Hay rutas, como el manejador de Delayed ACK o ksoftirqd, que pueden disparar de nuevo la planificación a través de tls_write_space() → tls_sw_write_space(). Esa función marca el bit BIT_TX_SCHEDULED y llama a schedule_delayed_work().
El resultado es una ventana de tiempo en la que cancel_delayed_work_sync() ya ha terminado, el objeto TLS se libera, y un worker se ejecuta más tarde sobre esa memoria. Dereferencia algo que ya no existe. Eso es un use-after-free de manual, y puede acabar en corrupción de memoria del kernel o en una caída completa del sistema.
A quién afecta
Cualquier máquina con un kernel que use kTLS y que abra y cierre conexiones TLS aceleradas por el núcleo. El rango de versiones afectadas es amplio:
- De la 5.3 hasta la 6.12.74.
- De la 6.13 hasta la 6.18.15.
- De la 6.19 hasta la 6.19.5.
Es decir, casi cualquier kernel moderno que no esté ya parcheado. Servidores que terminan TLS con descarga al kernel, balanceadores y máquinas con cargas de red intensas son los candidatos más expuestos a que la condición de carrera se dispare en producción.
Gravedad real
El vector CVSS (AV:N/AC:L/PR:N/UI:N) indica que el problema es alcanzable por red, sin privilegios previos ni interacción del usuario. Una condición de carrera es por naturaleza difícil de provocar de forma fiable, pero el impacto si se logra es serio: pérdida de integridad y disponibilidad del sistema, y la posibilidad de corromper estructuras del kernel. Por eso la nota tan alta.
Mitigación
La corrección es pequeña y limpia: se sustituye cancel_delayed_work_sync() por disable_delayed_work_sync(). La diferencia está en que disable_delayed_work_sync() además marca el trabajo como deshabilitado, de forma que cualquier intento posterior de volver a programarlo no surte efecto. Se cierra la ventana de carrera de raíz.
No hay configuración que puedas tocar para evitarlo sin parchear: actualiza el kernel a una versión corregida (6.12.75 o posterior en la rama estable, 6.18.16+, 6.19.6+, según corresponda) y reinicia. Si usas una distribución, espera al paquete de tu proveedor y aplícalo; muchas ofrecen además livepatch para evitar el reinicio. Revisa la ficha del kernel Linux para situar tu versión.