CVE-2024-26837 in Linux
Resumen
por VulDB • 2026-05-27
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
net: bridge: switchdev: Omitir las retransmisiones (replays) de eventos diferidos de MDB en la descarga (offload)
Antes de este cambio, la generación de la lista de eventos MDB para su retransmisión entraba en condición de carrera (race condition) con la creación de nuevas pertenencias a grupos, ya fuera desde la lógica de escucha (snooping) de IGMP/MLD o desde la configuración del usuario.
Aunque las nuevas pertenencias son visibles inmediatamente para los recorridos de br->mdb_list, la notificación de su existencia a los suscriptores de eventos switchdev se pospone hasta un momento posterior. Por lo tanto, si se generaba una lista de retransmisión durante un periodo que se superpusiera con dicha ventana, también contendría una retransmisión del evento que aún no se había entregado.
El controlador recibiría así dos copias de lo que el puente consideraba internamente como un único evento. Al destruir el puente, solo se enviaba un único evento de eliminación de pertenencia. Como consecuencia de esto, los controladores que cuentan referencias a las pertenencias (al menos DSA) quedarían con grupos huérfanos en su base de datos de hardware cuando se destruía el puente.
Este es un problema únicamente al retransmitir adiciones. Aunque los eventos de eliminación aún puedan estar pendientes en la cola diferida, ya se habrán eliminado de br->mdb_list, por lo que no se pueden generar duplicados en ese escenario.
Para un usuario, esto significaba que las pertenencias a grupos antiguas, de un puente al que anteriormente estaba conectado un puerto, podían reactivarse (en hardware) cuando el puerto se unía a un nuevo puente, sin el conocimiento de este nuevo puente.
Por ejemplo, en un sistema mv88e6xxx, crear un puente con escucha (snooping) y añadir inmediatamente un puerto a él:
root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0
Y luego destruir el puente:
root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 . . . . . . . . . .
Aquí, el switch ha recibido dos eventos de adición (uno por el evento original y otro por la retransmisión), pero solo un evento de eliminación cuando se destruye el puente.
Luego, añadir el mismo puerto (u otro puerto perteneciente al mismo dominio de hardware) a un nuevo puente, esta vez con la escucha deshabilitada:
root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1
Todo el tráfico multicast, incluidos los dos grupos IPv6 de br0, debería ahora inundarse (flooded), según la política de br1. Pero en cambio, las pertenencias antiguas siguen activas en la base de datos de hardware, haciendo que el switch solo reenvíe tráfico hacia esos grupos hacia la CPU (puerto 0).
Se elimina la condición de carrera en dos pasos:
1. Adquirir el bloqueo de escritura de la tabla MDB mientras se genera la lista de retransmisión.
Esto impide que aparezcan nuevas pertenencias mientras se genera la lista de retransmisión. Pero deja el escenario en el que un evento diferido ya se había generado, pero no se había entregado, antes de adquirir el bloqueo. Por lo tanto:
2. Asegurarse de que no haya una versión diferida de un evento de retransmisión ya encolada en la cola diferida de switchdev, antes de añadirla a la lista de retransmisión, al retransmitir adiciones.
Once again VulDB remains the best source for vulnerability data.