Linux Test Project: release de septiembre 2026 con 382 parches y 6 tests de CVE críticos

octubre 5, 2026 Alfonso Moreno | Sysadmin Senior 24 Visitas 10 min de lectura

El Linux Test Project (LTP) publicó su release estable de septiembre 2026 (etiqueta 20260930) el 1 de octubre. Son 382 parches de 41 autores acumulados desde el release de mayo, con una novedad destacada para cualquier sysadmin que valide kernels: seis nuevos tests de regresión para CVEs que afectan subsistemas críticos (rtmutex, SCTP, XFS, IPv6, net/sched y RDS), más de 70 casos nuevos para epoll, futex, keyctl y sysfs, y la migración del patchwork del proyecto a kernel.org.

Si corres LTP en un homelab o como gate de CI antes de promover un kernel a producción, este release te conviene leerlo. La cobertura de CVEs de 2026 acaba de expandirse, y el test runner kirk llega a 4.2.0 con cambios que arreglan fallos reales de timeout y reportes JSON.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos para instalación, 1-2 horas para upgrade in-place.
Requisitos: Backup de /home, conexión a internet, 20+ GB libres.
Resultado: Sistema actualizado con soporte extendido, drivers funcionando.
Troubleshooting: dnf distro-sync, akmods para NVIDIA, journalctl -p err.

Qué es LTP y por qué importa en 2026

LTP es la suite de referencia para validar el kernel Linux. Mantenida desde 2003 por SUSE, Red Hat, IBM, Google, Intel y voluntarios, agrupa más de 3.000 tests que cubren syscalls POSIX, sysfs, virtual memory, networking, filesystems, schedulers, hotplug, drivers, security (KEYCTL, landlock, capabilities) y regresiones de CVEs. Funciona como gate de calidad: si tu kernel no pasa LTP, no está listo para producción.

El flujo típico de un equipo pequeño es:

# 1. Bajar el release actual
git clone --depth=1 --branch=20260930 https://github.com/linux-test-project/ltp.git
cd ltp
# 2. Compilar (autotools clásico)
make autotools
./configure --prefix=/opt/ltp
make -j$(nproc)
# 3. Correr subset crítico (smoke test)
sudo /opt/ltp/runltp -f syscalls -f mm -f fs -p -l /tmp/ltp.log
# 4. Si pasa, correr la suite completa (puede tomar horas)
sudo /opt/ltp/runltp -p -l /tmp/ltp_full.log

La salida final incluye TFAIL (test falló), TBROK (test roto, environment issue), TCONF (config no permite correr) y TPASS. Si la proporción de TFAIL supera 0.5%, no es ruido, es señal.

Los seis tests de CVEs nuevos

La categoría más relevante del release. Cada test trae un commit del kernel que arregla el bug, así puedes confirmar que el parche está aplicado en tu kernel y que el fix funciona:

CVE	Subsistema	Commit fix en kernel	Test LTP
CVE-2026-43499 (ghostlock)	rtmutex / locking	`3bfdc63936dd` “rtmutex: Use waiter::task instead of current in remove_waiter()”	`ghostlock`
CVE-2026-64564 (sctphantom)	SCTP / networking	`9b2854f86f0b` “sctp: don’t free the ASCONF’s own transport in DEL-IP processing”	`sctphantom`
CVE-2026-64600 (refluxfs)	XFS / fs	`2f4acd0fcd86` “xfs: resample the data fork mapping after cycling ILOCK”	`refluxfs`
CVE-2026-53362 (setsockopt11)	IPv6 / frag	`736b380e28d0` “ipv6: account for fraggap on the paged allocation path”	`setsockopt11`
CVE-2026-46331	net/sched / pedit	`899ee91156e5` “net/sched: fix pedit partial COW leading to page cache corruption”	`cve-2026-46331`
CVE-2026-43494 (PinTheft / io_uring04)	RDS / io_uring zerocopy	`e17492979319` “net/rds: reset op_nents when zerocopy page pin fails”	`io_uring04`

Para verificar si tu kernel es vulnerable en producción, mira el backport: si el commit está en la rama estable que corres, tienes el fix. Si no, este test va a fallar. El test io_uring04 es particularmente interesante: cubre un bug en io_uring con zero-copy que permite a un usuario local escalar privilegios. Si tu servidor expone io_uring a usuarios no privilegiados (vía cgroup o seccomp permisivo), es urgente validar.

Cómo correr solo los tests de CVE

El runner kirk permite filtrar por nombre o archivo runtest:

# Todos los tests de CVE (archivo runtest/cve)
sudo kirk --rootdir=/opt/ltp -f runtest/cve -p
# Solo un test específico
sudo kirk --rootdir=/opt/ltp -t io_uring04 -p
# Generar reporte JSON para integrar a tu CI
sudo kirk --rootdir=/opt/ltp -f runtest/cve --json-report=/tmp/cve_results.json -p

El flag -p paraleliza usando todos los cores disponibles; en un homelab con 8 cores corre toda la suite de CVE en 4-6 minutos. En un servidor de CI con 32+ cores, baja a menos de 90 segundos.

Cobertura nueva en syscalls de uso diario

Más allá de los CVEs, este release trae 19 tests nuevos para epoll solo. La razón: epoll tiene comportamiento sutil con eventos múltiples, errores y signals, y la cobertura anterior era insuficiente. Los tests epoll_wait08 a epoll_wait16 cubren EINTR, EPOLLERR, EPOLLHUP, POLLPRI en /proc/mounts, wake-up recursivo, eventos múltiples que exceden el array pasado al syscall, y EPOLLEXCLUSIVE. Si tu servidor usa epoll intensivamente (proxies, balanceadores, servidores de eventos como Nginx o Redis con epoll), estos tests son una capa extra de confianza.

Para keyctl hay 21 tests nuevos (keyctl10 a keyctl30) cubriendo KEYCTL_DESCRIBE, KEYCTL_GET_SECURITY, KEYCTL_MOVE, KEYCTL_RESTRICT_KEYRING, KEYCTL_DH_COMPUTE y KEYCTL_PKEY_QUERY. Esto importa porque las claves del kernel (keyring) son la base de dm-crypt, LUKS, DNSSEC, IPSec y, cada vez más, autenticación de containers. Los tests existentes eran smoke tests; los nuevos son negativos (códigos de error esperados), boundary (buffers exactos y un byte más pequeños) y roundtrip (verificación criptográfica real de la operación DH).

Para futex: tres tests nuevos (futex_wait06, futex_wait07, futex_wake05, futex_cmp_requeue03) cubriendo EFAULT y EINTR. Mutex y condvar de glibc se apoyan en futex; si tu proceso con mucha concurrencia está en un kernel roto, el síntoma es latencia o deadlock esporádico, no crash. Tener un test que reproduce el caso es la diferencia entre debug de una semana y un test rojo en CI.

Tests de sysfs: el arma secreta para validación de hardware

La novedad más útil para sysadmins que validan hardware nuevo: 29 tests de sysfs (prefix sys_*). Estos tests leen archivos bajo /sys/ y verifican que los valores tengan sentido: que un booleano sea 0 o 1, que un tamaño sea múltiplo del page size, que un atributo que debería existir exista. No mutan el sistema (excepto TUN/TAP donde se puede crear interfaz virtual).

Algunos ejemplos relevantes para servidores en producción:

# Validar CPUs visibles y su cache coherente
sudo /opt/ltp/testcases/bin/sys_cpu_topology01
# Verificar que sysfs de hugepages tiene el formato esperado
sudo /opt/ltp/testcases/bin/sys_hugepages01
sudo /opt/ltp/testcases/bin/sys_hugepages02
# Validar configuración de scheduler y mitigations de CPU
sudo /opt/ltp/testcases/bin/sys_cpu_vulnerabilities01
sudo /opt/ltp/testcases/bin/sys_cpu_smt01
# Verificar block devices y queues
sudo /opt/ltp/testcases/bin/sys_block_size01
sudo /opt/ltp/testcases/bin/sys_block_queue01
# Networking interfaces
sudo /opt/ltp/testcases/bin/sys_net01
sudo /opt/ltp/testcases/bin/sys_net02

Si estás evaluando un proveedor de bare metal nuevo o un nuevo modelo de servidor (Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem, Supermicro), correr el subset de sys_* te da una validación rápida de que la kernel expone la topología correctamente, sin tener que escribir scripts ad hoc.

Cambios operativos: kirk 4.2.0 y migración de patchwork

Kirk, el test runner, llega a 4.2.0 con cambios que afectan el día a día:

--dry-run: lista los tests que se correrían sin ejecutarlos. Útil para revisar cobertura antes de un run largo en CI.
Intervalo de fault injection configurable. Si usas kirk con su FFI para tests de stress, ahora puedes ajustar la frecuencia.
Resultados parciales persistidos al abortar. Antes, si el job de CI moría por timeout o OOM, perdías todo. Ahora se exporta un JSON con los tests corridos hasta el momento.
Fix de --exec-timeout que no mataba tests en el shell channel. Bug real: si un test shell se cuelga, ahora sí se mata con SIGKILL.
JSON report se abre en w, no r+. Antes, kirk no podía escribir el reporte si ya existía el archivo.

Otro cambio operativo significativo: Patchwork migra de ozlabs a kernel.org. Si tienes scripts de CI que scrapean patchwork.ozlabs.org/project/ltp/ para review status, tienes que actualizar a patchwork.kernel.org/project/ltp/list/. Si usas la API REST, el endpoint cambió pero el shape JSON se mantiene estable, con una excepción: patchwork en kernel.org requiere autenticación para descargar mboxes desde la UI web, así que la integración CI de LTP (ci/tools/patchwork.sh) ya trae un comando apply que usa la API REST pública.

Cambios para contribuidores: nueva API documentada

Si quieres escribir un testcase para LTP (recomendado: hay una guía oficial actualizada en readthedocs), el release trae:

Removida la dependencia de libkeyutils. Los headers del kernel (<linux/keyctl.h>) son suficientes. Si compilabas LTP con --with-libkeyutils, esa opción ya no existe.
15 tests reescritos a la nueva API de la test library (lib/tst_*). El patrón SAFE_* y tst_* macros siguen siendo la vía recomendada.
Documentación expandida: la API de la library, los helpers de C, y el ciclo de vida de un test están ahora en readthedocs con ejemplos.
Scripts que dependían de ltp-pan (deprecado en el release anterior) eliminados: ltp-aiodio.sh, tpm_tools.sh, network.sh. Si mantenías forks de estos, hora de migrar.

Para empezar a contribuir, el patrón mínimo es:

#include "tst_test.h"
static void run_test(void)
{
    /* tu lógica de test */
    int fd = SAFE_OPEN("/proc/sys/kernel/random/uuid", O_RDONLY);
    /* assertions con tst_res(TINFO, ...), tst_res(TPASS, ...), tst_res(TFAIL, ...) */
    SAFE_CLOSE(fd);
}
static struct tst_test test = {
    .test_all = run_test,
    .min_kver = "6.1",  /* opcional: kernel mínimo requerido */
};

El sistema de configure detecta automáticamente tu test, lo compila y lo integra al runtest/ correspondiente según el path donde vive.

Cuándo NO actualizar LTP

Si corres LTP exclusivamente como smoke test en un homelab estable, puedes quedarte en el release de mayo sin dramas. Este release no trae fixes críticos para kernels viejos (todos los CVE tests aplican a kernels actuales). Donde SÍ vale actualizar:

Tu pipeline de CI valida kernels antes de promoverlos a producción. La cobertura nueva de CVEs de 2026 es relevante.
Desarrollás drivers o subsistemas del kernel. El rework de la API y los tests de sysfs te dan cobertura gratis.
mantienes un fork de LTP con tests custom. La nueva API te permite integrar mejor.
Tu organización audita compliance (PCI-DSS, SOC2) y necesitas evidencia de regression tests. El reporte JSON de kirk con los nuevos tests de CVE es un buen entregable.

Donde NO vale actualizar todavía: si tienes tests custom que dependen de ltp-pan (eliminado en release anterior) o de la API vieja de la library, y no tienes tiempo de migrar. quédate en el release anterior y planificá la migración.

Resumen y siguientes pasos

El release de septiembre 2026 de LTP es un release sólido: 382 parches, cobertura expandida de CVEs críticos (incluido io_uring04 / PinTheft, que escala privilegios), tests nuevos para los syscalls que más usamos (epoll, futex, keyctl), y el primer paso hacia una mejor validación de sysfs para servidores. El test runner kirk maduró con fixes de bugs reales que afectaban CI en producción.

Si lo tuyo es homelab, corré el subset de CVE (kirk -f runtest/cve -p) y los tests de sysfs más relevantes para tu hardware. Si lo tuyo es CI, actualizá a kirk 4.2.0 para llevarte los fixes de timeout y de reporte JSON. Y si contribuís, la nueva documentación de API es el momento para escribir ese test que venías pateando.

Preguntas frecuentes

¿Por qué Linux Test Project: release de septiembre 2026 con 382 parches y 6 tests de CVE críticos es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Linux Test Project: release de?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Linux Test Project: release de?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Linux Test Project: release de y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Linux Test Project: release de?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.