CVE-2026-43499 (rtmutex) vs CVE-2026-46242 (epoll), ¿ que es epoll y rtmutex ? Explicación como si estuviera en primero.

MUTEX Y EPOLL ¿que son y que hacen?

Las explicaciones en los CVE son complicadas, hablan de epoll, eventpoll, mutex, rtmutex etc pero veamos que significa cada cosa. Y antes de hablar de rt-mutex hay que saber que hace mutex.

¿Qué es un mutex?

Un mutex sirve para proteger un recurso compartido.

Se usa cuando varios hilos o procesos podrían acceder al mismo recurso al mismo tiempo.

Ejemplos de recursos compartidos:

- Una variable en memoria.
- Una estructura de datos.
- Un fichero que varios hilos modifican.
- Una cola de trabajos.
- Una conexión compartida.

Funcionamiento básico:

- Hilo A bloquea el mutex.
- Hilo A usa el recurso.
- Mientras tanto, Hilo B espera.
- Hilo A libera el mutex.
- Hilo B puede continuar.

Objetivo: Evitar accesos simultáneos que puedan provocar datos corruptos o resultados incorrectos.

¿Qué es epoll?

epoll sirve para esperar eventos en descriptores de fichero.

En Linux, un descriptor de fichero puede representar:

- Un socket.
- Un pipe.
- Un fichero.
- Un eventfd.
- Un timerfd.
- Un signalfd.

* lo que termina en FD es por File descriptor, entonces signalfd = syscall o señal recibida desde un FD.

epoll permite vigilar muchos descriptores y saber cuáles están listos.

Ejemplos:

- Un socket tiene datos para leer.
- Un socket permite escribir.
- Ha llegado una nueva conexión.
- Un pipe contiene datos.
- Un temporizador ha expirado.

Objetivo:
Esperar eventos de entrada/salida sin recorrer continuamente todos los descriptores.

 Diferencia Mutex vz Epoll

MUTEX: Protege un recurso compartido frente a accesos simultáneos.
EPOLL: Espera eventos de entrada/salida en descriptores de fichero.

Ejemplo como actúan ambos:

En un  servidor con muchos clientes;

epoll detecta qué socket tiene datos disponibles.
Después, varios hilos pueden procesar clientes distintos.
Si esos hilos acceden a una misma lista global de usuarios, puede ser necesario usar un mutex para proteger esa lista.

Así que tenemos a los 2 trabajando:

epoll responde: ¿Qué descriptor tiene un evento?
mutex responde: ¿Quién puede acceder ahora al recurso compartido?

Por tanto:

mutex:
- Sincronización.
- Exclusión mutua.
- Protege memoria o recursos compartidos.
- Puede bloquear temporalmente a otros hilos.

¿Donde entra rtmutex?

Rtmutex, no es más que un añadido a mutex que gestiona prioridades de forma más eficiente y tiene una función para que un evento pueda heredar temporalmente la prioridad de la tarea que espera, para que un evento de alta prioridad no espere de más a uno de baja prioridad, el de baja prioridad hereda la alta prioridad del evento que espera para acabar antes.

epoll:
- Multiplexación de entrada/salida.
- Vigila descriptores de fichero.
- Detecta sockets, pipes y otros descriptores listos.
- Puede bloquear hasta que ocurra un evento.

Así que rtmutex y epoll no son módulos, están integrados profundamente en el kernel y son cosas muy distintas pero pueden trabajar juntos:

epoll detecta trabajo disponible.
mutex protege los datos compartidos mientras ese trabajo se procesa.

epoll es parte de fs, alojado en fs/eventpoll.c > https://docs.kernel.org/filesystems/api-summary.html#eventpoll-epoll-interfaces

Mutex y rt-mutex: https://docs.kernel.org/locking/mutex-design.html |  https://docs.kernel.org/locking/rt-mutex-design.html 

Sabiendo esto, ¿ donde entran los bugs actuales ?

• El Bug en RT-Mutex (CVE-2026-43499 - GhostLock): Ocurría al quitar una tarea de la lista de espera (remove_waiter). El kernel se confundía de tarea al limpiar el estado, dejando un puntero corrupto (un fallo de Use-After-Free). Alguien con pocos privilegios provocaba esto adrede para engañar al kernel y volverse root.

• El Bug en Epoll (CVE-2026-46242 - Bad Epoll): Cuando se usaba epoll dentro de otro epoll y se cerraban a la vez, el kernel sufría un race condition, liberando la memoria antes de tiempo, lo que permite escalar a root.

Creo que se entiende más o menos ¿no ?  y si no pregúntale a la IA