CVE-2024-26837

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: switchdev: omitir repeticiones MDB de eventos diferidos durante la descarga. Antes de este cambio, la generación de la lista de eventos MDB para reproducir competiría con la creación de nuevas membresías de grupos, ya sea desde la lógica de espionaje IGMP/MLD o desde la configuración del usuario. Si bien las nuevas membresías son visibles inmediatamente para los caminantes de br->mdb_list, la notificación de su existencia a los suscriptores del evento switchdev se difiere hasta un momento posterior. Entonces, si se generó una lista de reproducción durante un tiempo que se superpuso con dicha ventana, también contendría una repetición del evento aún no entregado. El conductor recibiría así dos copias de lo que internamente el puente consideraba un único evento. Por lo tanto, tras la destrucción del puente, solo se envió un evento de eliminación de membresía. Como consecuencia de esto, los controladores que hacen referencia al recuento de membresías (al menos DSA) quedarían con grupos huérfanos en su base de datos de hardware cuando se destruyera el puente. Esto sólo es un problema al reproducir adiciones. Si bien es posible que los eventos de eliminación aún estén 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 antiguas membresías de grupos, de un puente al que previamente se había conectado un puerto, podían reanimarse (en hardware) cuando el puerto se unía a un nuevo puente, sin el conocimiento del nuevo puente. Por ejemplo, en un sistema mv88e6xxx, cree un puente de vigilancia e inmediatamente agréguele un puerto: 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 destruye el puente: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu DIRECCIÓN FID ESTADO QF 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 estático - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 estático - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ Los dos grupos IPv6 permanecen en la base de datos de hardware porque el puerto (x3) recibe dos notificaciones sobre la membresía del anfitrión: una vez a través del evento original y otra a través de una repetición. Dado que solo se envía una notificación de eliminación, el recuento permanece en 1 cuando se destruye el puente. Luego agregue el mismo puerto (u otro puerto que pertenezca al mismo dominio de hardware) a un nuevo puente, esta vez con el snooping deshabilitado: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 Toda la multidifusión, incluidos los dos grupos IPv6 de br0, ahora debería estar inundada, de acuerdo con la política de br1. Pero, en cambio, las membresías antiguas todavía están activas en la base de datos del hardware, lo que hace que el conmutador solo reenvíe el tráfico a esos grupos hacia la CPU (puerto 0). Elimine la carrera en dos pasos: 1. Tome el bloqueo del lado de escritura del MDB mientras genera la lista de reproducción. Esto evita que aparezcan nuevas membresías mientras generamos la lista de reproducción. Pero deja el escenario en el que ya se generó un evento diferido, pero no se entregó, antes de que tomáramos el bloqueo. Por lo tanto: 2. Asegúrese de que ninguna versión diferida de un evento de reproducción ya esté en cola en la cola diferida de switchdev, antes de agregarla a la lista de reproducción, al reproducir adiciones.

A flaw was found in the Linux kernel. A race condition in network bridge management could lead to a denial of service.