CVE-2024-26837 (GCVE-0-2024-26837)
Vulnerability from cvelistv5
Published
2024-04-17 10:10
Modified
2025-05-04 08:57
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: 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 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925fPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754dbPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4bPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925fPatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754dbPatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4bPatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8Patch
Impacted products
Vendor Product Version
Linux Linux Version: 4f2673b3a2b6246729a1ff13b8945a040839dbd3
Version: 4f2673b3a2b6246729a1ff13b8945a040839dbd3
Version: 4f2673b3a2b6246729a1ff13b8945a040839dbd3
Version: 4f2673b3a2b6246729a1ff13b8945a040839dbd3
 Create a notification for this product.
   Linux Linux Version: 5.13
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-26837",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-05-28T19:58:57.584578Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-04T17:49:06.995Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T00:14:13.669Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "include/net/switchdev.h",
            "net/bridge/br_switchdev.c",
            "net/switchdev/switchdev.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "2d5b4b3376fa146a23917b8577064906d643925f",
              "status": "affected",
              "version": "4f2673b3a2b6246729a1ff13b8945a040839dbd3",
              "versionType": "git"
            },
            {
              "lessThan": "603be95437e7fd85ba694e75918067fb9e7754db",
              "status": "affected",
              "version": "4f2673b3a2b6246729a1ff13b8945a040839dbd3",
              "versionType": "git"
            },
            {
              "lessThan": "e0b4c5b1d760008f1dd18c07c35af0442e54f9c8",
              "status": "affected",
              "version": "4f2673b3a2b6246729a1ff13b8945a040839dbd3",
              "versionType": "git"
            },
            {
              "lessThan": "dc489f86257cab5056e747344f17a164f63bff4b",
              "status": "affected",
              "version": "4f2673b3a2b6246729a1ff13b8945a040839dbd3",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "include/net/switchdev.h",
            "net/bridge/br_switchdev.c",
            "net/switchdev/switchdev.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.13"
            },
            {
              "lessThan": "5.13",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.80",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.19",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.7.*",
              "status": "unaffected",
              "version": "6.7.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.8",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.80",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.19",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.7.7",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.8",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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-\u003emdb_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-\u003emdb_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\u0027s\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 \u0026\u0026 \\\n    \u003e 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\u0027s 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 \u0026\u0026 \\\n    \u003e 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."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-04T08:57:38.464Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f"
        },
        {
          "url": "https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db"
        },
        {
          "url": "https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8"
        },
        {
          "url": "https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b"
        }
      ],
      "title": "net: bridge: switchdev: Skip MDB replays of deferred events on offload",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-26837",
    "datePublished": "2024-04-17T10:10:04.164Z",
    "dateReserved": "2024-02-19T14:20:24.182Z",
    "dateUpdated": "2025-05-04T08:57:38.464Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-26837\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-04-17T10:15:09.757\",\"lastModified\":\"2025-04-02T13:18:18.407\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"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-\u003emdb_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-\u003emdb_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\u0027s\\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 \u0026\u0026 \\\\\\n    \u003e 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\u0027s 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 \u0026\u0026 \\\\\\n    \u003e 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-\u0026gt;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-\u0026gt;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 \u0026amp;\u0026amp; \\\\ \u0026gt; 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 \u0026amp;\u0026amp; \\\\ \u0026gt; 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.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":4.7,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.0,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-362\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.13\",\"versionEndExcluding\":\"6.1.80\",\"matchCriteriaId\":\"9670B0EF-CFF4-4E0D-9772-88012D564024\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.19\",\"matchCriteriaId\":\"8D82004C-B2AE-4048-9344-32EFF65953B0\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.7.7\",\"matchCriteriaId\":\"575EE16B-67F2-4B5B-B5F8-1877715C898B\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"B9F4EA73-0894-400F-A490-3A397AB7A517\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"056BD938-0A27-4569-B391-30578B309EE3\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"F02056A5-B362-4370-9FF8-6F0BD384D520\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"62075ACE-B2A0-4B16-829D-B3DA5AE5CC41\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"A780F817-2A77-4130-A9B7-5C25606314E3\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-02T00:14:13.669Z\"}}, {\"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-26837\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-05-28T19:58:57.584578Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-05-28T19:59:02.417Z\"}, \"title\": \"CISA ADP Vulnrichment\"}], \"cna\": {\"title\": \"net: bridge: switchdev: Skip MDB replays of deferred events on offload\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"4f2673b3a2b6246729a1ff13b8945a040839dbd3\", \"lessThan\": \"2d5b4b3376fa146a23917b8577064906d643925f\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"4f2673b3a2b6246729a1ff13b8945a040839dbd3\", \"lessThan\": \"603be95437e7fd85ba694e75918067fb9e7754db\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"4f2673b3a2b6246729a1ff13b8945a040839dbd3\", \"lessThan\": \"e0b4c5b1d760008f1dd18c07c35af0442e54f9c8\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"4f2673b3a2b6246729a1ff13b8945a040839dbd3\", \"lessThan\": \"dc489f86257cab5056e747344f17a164f63bff4b\", \"versionType\": \"git\"}], \"programFiles\": [\"include/net/switchdev.h\", \"net/bridge/br_switchdev.c\", \"net/switchdev/switchdev.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"5.13\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.13\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.1.80\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.1.*\"}, {\"status\": \"unaffected\", \"version\": \"6.6.19\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.7.7\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.7.*\"}, {\"status\": \"unaffected\", \"version\": \"6.8\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"include/net/switchdev.h\", \"net/bridge/br_switchdev.c\", \"net/switchdev/switchdev.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f\"}, {\"url\": \"https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db\"}, {\"url\": \"https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8\"}, {\"url\": \"https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b\"}], \"x_generator\": {\"engine\": \"bippy-5f407fcff5a0\"}, \"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-\u003emdb_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-\u003emdb_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\u0027s\\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 \u0026\u0026 \\\\\\n    \u003e 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\u0027s 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 \u0026\u0026 \\\\\\n    \u003e 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.\"}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2024-12-19T08:48:24.231Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-26837\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2024-12-19T08:48:24.231Z\", \"dateReserved\": \"2024-02-19T14:20:24.182Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-04-17T10:10:04.164Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}