CVE-2026-53264: la carrera de `tc_action` en net/sched de Linux convierte el acceso local a filtros en root

CVE

CVE-2026-53264

CWE

CWE-362, CWE-416

Sistemas afectados

• Kernels de Linux desde `4.14` en adelante hasta las líneas corregidas relevantes de upstream, incluyendo `< 5.10.259`, `5.11.x < 5.15.210`, `5.16.x < 6.1.176`, `6.2.x < 6.6.143`, `6.7.x < 6.12.94`, `6.13.x < 6.18.36` y `6.19.x < 7.0.13`
• Distribuciones Linux empresariales y para desarrolladores que exponen el ciclo de vida de acciones de `net/sched` vulnerable y que todavía no han retroportado la corrección de liberación diferida por RCU a sus paquetes de kernel en producción
• Estaciones de trabajo de desarrolladores, ejecutores de CI autogestionados, bastiones Linux compartidos, sistemas de laboratorio y hosts de contenedores donde código local no confiable puede crear espacios de nombres de usuario y alcanzar operaciones netlink de control de tráfico
• Hosts que también exponen los mismos requisitos previos del exploit público señalados por STAR Labs, incluyendo las rutas `clsact` / `flower` y módulos de acción como `CONFIG_NET_ACT_GACT`

CVE-2026-53264 es el candidato más defendible de las últimas tres días para /research porque el análisis del exploit público solo se publicó a finales de julio, todavía no está cubierto en este repositorio, e importa directamente a los equipos de seguridad de aplicaciones que operan hosts Linux para desarrolladores o ejecutores de CI. El fallo vive en el subsistema de control de tráfico del kernel de Linux en lugar de en npm o PyPI, pero precisamente por eso importa: una vez que un paquete malicioso, un paso de compilación comprometido o un fallo de aplicación de bajo privilegio obtiene ejecución de código local, este fallo del kernel puede proporcionar la segunda etapa de root del host.

Lo que cambió esta semana no fue solo la existencia del fallo. El desarrollo importante de finales de julio fue el artículo público de exploit de STAR Labs, que muestra cómo la carrera en net/sched puede convertirse en una escalada de privilegios local práctica en CentOS Stream 9, junto con un enriquecimiento fresco de NVD/CISA que ajustó los rangos afectados y los metadatos de explotación. Para los defensores, eso mueve el problema de “fallo de kernel corregido en feeds de metadatos” a “cadena de explotación públicamente explicada que deberías modelar activamente contra flotas de compilación y estaciones de trabajo Linux.”

Qué está afectado

El proyecto afectado es el kernel de Linux, específicamente el ciclo de vida de acciones de net/sched en include/net/act_api.h y net/sched/act_api.c. Los metadatos públicos de vulnerabilidad ahora rastrean el problema desde Linux 4.14 en adelante, con las primeras versiones corregidas upstream en cada línea estable mantenida mostradas a continuación:

Línea upstream	Primera versión corregida
4.14 hasta 5.10.x	5.10.259
5.11.x hasta 5.15.x	5.15.210
5.16.x hasta 6.1.x	6.1.176
6.2.x hasta 6.6.x	6.6.143
6.7.x hasta 6.12.x	6.12.94
6.13.x hasta 6.18.x	6.18.36
6.19.x hasta 7.0.x	7.0.13

Los retroportes de distribución todavía importan más que la salida cruda de uname -r, pero esos puntos de corte estables son el punto de partida correcto para la delimitación. Si mantienes:

• ejecutores de CI autogestionados en Linux,
• estaciones de trabajo de desarrolladores compartidas,
• bastiones o hosts de ingeniería multiusuario,
• hosts de contenedores donde las cargas de trabajo ya pueden ejecutar código local,

entonces este es el tipo de problema de kernel que merece atención de AppSec aunque sea “local”. Una dependencia envenenada no necesita un punto de entrada de kernel remoto si ya tiene una shell.

Causa raíz: búsqueda protegida por RCU, liberación inmediata

El flujo vulnerable es conceptualmente simple. tcf_idr_check_alloc() busca un objeto tc_action compartido bajo rcu_read_lock(), y luego intenta tomar una referencia viva:

rcu_read_lock();
p = idr_find(&idrinfo->action_idr, *index);
...
if (!refcount_inc_not_zero(&p->tcfa_refcnt)) {
        rcu_read_unlock();
        return -EAGAIN;
}

Esa ruta de búsqueda asume que RCU protegerá a los lectores el tiempo suficiente para que la comprobación de refcount tenga sentido. El fallo es que el lado de eliminación puede soltar la última referencia y liberar el objeto inmediatamente en lugar de diferir la liberación hasta después del período de gracia de RCU. En la ruta vulnerable, CPU0 puede seguir manteniendo p desde idr_find() mientras CPU1 ya lo ha eliminado y liberado con kfree().

Por eso el registro de cambio de NVD describe explícitamente la carrera como:

CPU0: p = idr_find(idr, index)
CPU1: idr_remove(idr, index); tcf_action_cleanup(p); kfree(p)
CPU0: refcount_inc_not_zero(&p->tcfa_refcnt)  <-- UAF

La corrección es pequeña pero precisa. En lugar de liberar la acción inmediatamente, la ruta parcheada restaura la destrucción diferida por RCU:

struct tc_action {
        ...
        struct rcu_head tcfa_rcu;
        ...
}

static void free_tcf(struct tc_action *p)
{
        ...
        kfree_rcu(p, tcfa_rcu);
}

Ese cambio cierra exactamente la brecha de seguridad que la explotación necesita. Después de idr_remove(), el objeto ya no es alcanzable para nuevas búsquedas, pero los lectores existentes tampoco vuelven a competir con un kfree() en crudo mientras todavía mantienen un puntero protegido por RCU.

Por qué la ruta de exploit público importa a los equipos de AppSec

El artículo de STAR Labs es lo que hace que valga la pena un nuevo artículo en lugar de una nota discreta en un boletín semanal. El exploit publicado no depende de ya ser root ni de comportamiento oscuro del hardware. Muestra cómo un atacante local puede pasar de ejecución ordinaria en espacio de usuario a control del kernel mediante:

1. la creación de un espacio de nombres de usuario separado para obtener CAP_NET_ADMIN relativo a la ruta netlink relevante;
2. el uso de RTM_NEWTFILTER y RTM_DELTFILTER en lugar de la API de gestión de acciones, menos alcanzable;
3. la elección de una qdisc clsact y una ruta de filtro flower para que la operación evite la ruta más pesada de rtnl_lock();
4. la carrera entre hilos de vinculación y eliminación alrededor de un índice de acción compartido;
5. la reclamación de la víctima kmalloc-256 liberada con objetos user_key_payload impulsados por KEYCTL_UPDATE;
6. el pivote a través de la entrada de vtable ops reclamada cuando tcf_action_fill_size() desreferencia act->ops->get_fill_size.

El artículo público es explícito sobre los requisitos previos de explotación:

requires CONFIG_NET_ACT_GACT=y or m
requires CONFIG_NET_CLS_FLOWER=y or m
requires unprivileged user namespaces to be enabled

Eso no significa que solo estén en riesgo máquinas de investigación especializadas. Significa que la ruta de exploit es especialmente relevante en los sistemas Linux exactos que ya preocupan a los equipos de AppSec: escritorios de desarrolladores, entornos de prueba, trabajadores de CI y máquinas de laboratorio que llevan una amplia cobertura de funciones del kernel y donde los espacios de nombres de usuario a menudo están disponibles para contenedores o herramientas en sandbox.

La carrera no es teórica

La parte más útil del análisis de STAR Labs no es el término de moda sobre la caza de bugs asistida por IA. Es el detalle de ingeniería del exploit que muestra que el fallo no es solo una primitiva de fallo.

El hilo de vinculación abusa de la ruta de error en tcf_action_init() solicitando dos acciones: un índice de acción compartido real y una acción intencionadamente malformada. Eso hace que la acción objetivo se obtenga durante la inicialización, pero el filtro nunca se confirma:

for (i = 1; i <= TCA_ACT_MAX_PRIO && tb[i]; i++) {
        act = tcf_action_init_1(...);          // fetch action
        if (IS_ERR(act)) {
                err = PTR_ERR(act);
                goto err;                      // abort before insert_many
        }
        actions[i - 1] = act;
}

tcf_idr_insert_many(actions, init_res);

Eso importa porque da al atacante oportunidades repetidas de bajo costo de golpear tcf_idr_check_alloc() sin pagar el coste de un ciclo completo de creación y eliminación en cada intento de carrera. El hilo de eliminación solo necesita seguir reinsertando y eliminando el mismo índice de acción.

Una vez que el tc_action liberado vuelve a kmalloc-256, el artículo muestra cómo operaciones repetidas de KEYCTL_UPDATE lo reclaman como datos user_key_payload, superponiendo bytes controlados por el atacante con el puntero de vtable ops. La cadena final publicada luego sobrescribe core_pattern y colapsa un proceso hijo para que Linux ejecute una carga respaldada por memfd como el manejador de volcado de núcleo en el espacio de nombres inicial. Esa es una ruta a root muy específica de Linux, pero también muy práctica.

La conclusión operativa es simple: el análisis público demuestra una ruta desde ejecución de código local a compromiso completo del host, no solo un oops del kernel.

Por qué debería estar en una biblioteca de investigación de cadena de suministro de software

Las escaladas de privilegios de kernel como CVE-2026-53264 son parte de la historia de la cadena de suministro de software siempre que el punto de apoyo de primera etapa sea herramientas de desarrollador o CI:

• una dependencia npm maliciosa aterriza en un ejecutor de compilación Linux;
• una rueda PyPI comprometida se importa en la estación de trabajo de un investigador;
• un paso de GitHub Action envenenado deja una shell de bajo privilegio en un ejecutor autogestionado;
• un fallo de aplicación interna produce ejecución local dentro de una cuenta de usuario en un host de ingeniería compartido.

En cada caso, el kernel se convierte en el que rompe el límite de confianza. Por eso pertenece junto a la investigación de compromisos de paquetes en lugar de en un cubo separado de “solo fallos del SO”.

Detección y delimitación

Empieza comprobando si el host está siquiera en una línea de kernel vulnerable y si los requisitos previos del exploit público son plausibles:

uname -r
sysctl kernel.unprivileged_userns_clone 2>/dev/null
rg 'CONFIG_NET_(ACT_GACT|CLS_FLOWER)' "/boot/config-$(uname -r)"

Si tu configuración de kernel vive en otro lugar, adapta en consecuencia. Para compilaciones basadas en módulos, confirma si los módulos de control de tráfico relevantes están disponibles:

modinfo act_gact 2>/dev/null
modinfo cls_flower 2>/dev/null

Luego inspecciona los changelogs del proveedor en lugar de confiar solo en las cadenas de versión:

rpm -q --changelog kernel | rg 'CVE-2026-53264|act_api: use RCU with deferred freeing'

apt changelog "linux-image-$(uname -r)" 2>/dev/null | \
  rg 'CVE-2026-53264|act_api: use RCU with deferred freeing'

Prioriza los sistemas donde todo lo siguiente sea cierto:

1. código no confiable o semi confiable puede ejecutarse localmente;
2. los espacios de nombres de usuario están habilitados o son ampliamente utilizados;
3. la línea de kernel todavía es vulnerable o el estado del retroporte es desconocido;
4. el host es lo suficientemente valioso como para que el root local cambie materialmente el incidente.

Ese conjunto suele incluir ejecutores autogestionados y máquinas Linux compartidas de desarrolladores antes de incluir aplicaciones de producción estrechamente bloqueadas.

Remediación

Parchea a un kernel de proveedor que incluya la corrección basada en kfree_rcu() y reinicia en él. No te detengas en la instalación del paquete; confirma que el kernel en ejecución es el remediado.

Si necesitas reducción de exposición a corto plazo mientras se despliega el parcheo, el análisis del exploit público señala los puntos de fricción más relevantes:

• restringe o desactiva los espacios de nombres de usuario sin privilegios donde eso no rompa las cargas de trabajo requeridas;
• reduce la disponibilidad de capacidades de control de tráfico en hosts compartidos;
• trata las estaciones de trabajo Linux de desarrolladores y los ejecutores de CI autogestionados como objetivos prioritarios de parcheo de kernel, no solo las flotas de servidores.

Esos son controles compensatorios, no un sustituto del kernel corregido. El artículo público ya mostró una ruta confiable a root en un objetivo Linux empresarial convencional, y NVD ahora captura las líneas estables exactas corregidas necesarias para la triage.

Para los equipos de AppSec, la lección es más amplia que un solo CVE: siempre que un incidente de dependencia o un compromiso de CI produzca “solo” ejecución de código local en Linux, deberías preguntarte inmediatamente qué amplificadores de privilegio de kernel siguen presentes en ese host. CVE-2026-53264 es el recordatorio más reciente de que la respuesta todavía puede ser “suficiente para convertirse en root”.

De la investigación a la remediación

Comprueba si este patrón existe en tu código

Convierte esta investigación en un flujo de remediación. Analiza dependencias y manifiestos para detectar riesgos similares en la cadena de suministro y prioriza las correcciones con contexto de alcanzabilidad.

Explorar el análisis de dependencias Solicitar demo

Referencias

• STAR Labs: cuando la IA hace que los 0-days parezcan N-days
• NVD: CVE-2026-53264
• Parche estable de Linux 5057e1aca011
• Espejo del parche del kernel con el diff de la ruta de liberación
• Infosecurity Magazine: resumen del exploit público