CVE-2024-26837

{"id": "CVE-2024-26837", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 4.7, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.0}]}, "published": "2024-04-17T10:15:09.757", "references": [{"url": "https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-362"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: switchdev: Skip MDB replays of deferred events on offload\n\nBefore this change, generation of the list of MDB events to replay\nwould race against the creation of new group memberships, either from\nthe IGMP/MLD snooping logic or from user configuration.\n\nWhile new memberships are immediately visible to walkers of\nbr->mdb_list, the notification of their existence to switchdev event\nsubscribers is deferred until a later point in time. So if a replay\nlist was generated during a time that overlapped with such a window,\nit would also contain a replay of the not-yet-delivered event.\n\nThe driver would thus receive two copies of what the bridge internally\nconsidered to be one single event. On destruction of the bridge, only\na single membership deletion event was therefore sent. As a\nconsequence of this, drivers which reference count memberships (at\nleast DSA), would be left with orphan groups in their hardware\ndatabase when the bridge was destroyed.\n\nThis is only an issue when replaying additions. While deletion events\nmay still be pending on the deferred queue, they will already have\nbeen removed from br->mdb_list, so no duplicates can be generated in\nthat scenario.\n\nTo a user this meant that old group memberships, from a bridge in\nwhich a port was previously attached, could be reanimated (in\nhardware) when the port joined a new bridge, without the new bridge's\nknowledge.\n\nFor example, on an mv88e6xxx system, create a snooping bridge and\nimmediately add a port to it:\n\n root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\\n > ip link set dev x3 up master br0\n\nAnd then destroy the bridge:\n\n root@infix-06-0b-00:~$ ip link del dev br0\n root@infix-06-0b-00:~$ mvls atu\n ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a\n DEV:0 Marvell 88E6393X\n 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . .\n 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . .\n ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a\n root@infix-06-0b-00:~$\n\nThe two IPv6 groups remain in the hardware database because the\nport (x3) is notified of the host's membership twice: once via the\noriginal event and once via a replay. Since only a single delete\nnotification is sent, the count remains at 1 when the bridge is\ndestroyed.\n\nThen add the same port (or another port belonging to the same hardware\ndomain) to a new bridge, this time with snooping disabled:\n\n root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\\n > ip link set dev x3 up master br1\n\nAll multicast, including the two IPv6 groups from br0, should now be\nflooded, according to the policy of br1. But instead the old\nmemberships are still active in the hardware database, causing the\nswitch to only forward traffic to those groups towards the CPU (port\n0).\n\nEliminate the race in two steps:\n\n1. Grab the write-side lock of the MDB while generating the replay\n list.\n\nThis prevents new memberships from showing up while we are generating\nthe replay list. But it leaves the scenario in which a deferred event\nwas already generated, but not delivered, before we grabbed the\nlock. Therefore:\n\n2. Make sure that no deferred version of a replay event is already\n enqueued to the switchdev deferred queue, before adding it to the\n replay list, when replaying additions."}, {"lang": "es", "value": "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\u00f3n de la lista de eventos MDB para reproducir competir\u00eda con la creaci\u00f3n de nuevas membres\u00edas de grupos, ya sea desde la l\u00f3gica de espionaje IGMP/MLD o desde la configuraci\u00f3n del usuario. Si bien las nuevas membres\u00edas son visibles inmediatamente para los caminantes de br->mdb_list, la notificaci\u00f3n de su existencia a los suscriptores del evento switchdev se difiere hasta un momento posterior. Entonces, si se gener\u00f3 una lista de reproducci\u00f3n durante un tiempo que se superpuso con dicha ventana, tambi\u00e9n contendr\u00eda una repetici\u00f3n del evento a\u00fan no entregado. El conductor recibir\u00eda as\u00ed dos copias de lo que internamente el puente consideraba un \u00fanico evento. Por lo tanto, tras la destrucci\u00f3n del puente, solo se envi\u00f3 un evento de eliminaci\u00f3n de membres\u00eda. Como consecuencia de esto, los controladores que hacen referencia al recuento de membres\u00edas (al menos DSA) quedar\u00edan con grupos hu\u00e9rfanos en su base de datos de hardware cuando se destruyera el puente. Esto s\u00f3lo es un problema al reproducir adiciones. Si bien es posible que los eventos de eliminaci\u00f3n a\u00fan est\u00e9n pendientes en la cola diferida, ya se habr\u00e1n 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\u00edas de grupos, de un puente al que previamente se hab\u00eda conectado un puerto, pod\u00edan reanimarse (en hardware) cuando el puerto se un\u00eda a un nuevo puente, sin el conocimiento del nuevo puente. Por ejemplo, en un sistema mv88e6xxx, cree un puente de vigilancia e inmediatamente agr\u00e9guele 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\u00d3N 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\u00e1tico - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 est\u00e1tico - - 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\u00eda del anfitri\u00f3n: una vez a trav\u00e9s del evento original y otra a trav\u00e9s de una repetici\u00f3n. Dado que solo se env\u00eda una notificaci\u00f3n de eliminaci\u00f3n, 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\u00f3n, incluidos los dos grupos IPv6 de br0, ahora deber\u00eda estar inundada, de acuerdo con la pol\u00edtica de br1. Pero, en cambio, las membres\u00edas antiguas todav\u00eda est\u00e1n activas en la base de datos del hardware, lo que hace que el conmutador solo reenv\u00ede el tr\u00e1fico 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\u00f3n. Esto evita que aparezcan nuevas membres\u00edas mientras generamos la lista de reproducci\u00f3n. Pero deja el escenario en el que ya se gener\u00f3 un evento diferido, pero no se entreg\u00f3, antes de que tom\u00e1ramos el bloqueo. Por lo tanto: 2. Aseg\u00farese de que ninguna versi\u00f3n diferida de un evento de reproducci\u00f3n ya est\u00e9 en cola en la cola diferida de switchdev, antes de agregarla a la lista de reproducci\u00f3n, al reproducir adiciones."}], "lastModified": "2025-04-02T13:18:18.407", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "9670B0EF-CFF4-4E0D-9772-88012D564024", "versionEndExcluding": "6.1.80", "versionStartIncluding": "5.13"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "8D82004C-B2AE-4048-9344-32EFF65953B0", "versionEndExcluding": "6.6.19", "versionStartIncluding": "6.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "575EE16B-67F2-4B5B-B5F8-1877715C898B", "versionEndExcluding": "6.7.7", "versionStartIncluding": "6.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "B9F4EA73-0894-400F-A490-3A397AB7A517"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "056BD938-0A27-4569-B391-30578B309EE3"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "F02056A5-B362-4370-9FF8-6F0BD384D520"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "62075ACE-B2A0-4B16-829D-B3DA5AE5CC41"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "A780F817-2A77-4130-A9B7-5C25606314E3"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}