CVE-2024-26837: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2024-26837

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.

AI Analysis

Technical Summary

CVE-2024-26837 is a vulnerability in the Linux kernel's network bridge subsystem, specifically affecting the multicast database (MDB) event replay mechanism in switchdev-enabled bridges. The issue arises from a race condition during the generation of the list of MDB events to replay. When new multicast group memberships are created—either via IGMP/MLD snooping or user configuration—they are immediately visible in the bridge's MDB list, but notifications to switchdev event subscribers are deferred. If the replay list is generated during this deferral window, it may include duplicate events, causing the driver to receive two copies of what the bridge considers a single event. Upon bridge destruction, only one deletion event is sent, leaving the driver with orphaned multicast group memberships in its hardware database. This leads to stale multicast groups persisting in hardware even after the bridge is removed. Consequently, when a port is moved to a new bridge, these old group memberships can be incorrectly reactivated, causing multicast traffic to be forwarded based on outdated group membership information. This can disrupt multicast traffic handling, leading to potential network misbehavior or traffic leakage. The vulnerability is demonstrated on Marvell mv88e6xxx switch hardware, where IPv6 multicast groups remain in the hardware database after bridge deletion and affect forwarding behavior on a new bridge. The fix involves two key steps: acquiring a write lock on the MDB during replay list generation to prevent new memberships from appearing mid-process, and ensuring no deferred replay events are enqueued before adding events to the replay list. This eliminates the race condition and prevents duplicate event replays. The vulnerability affects Linux kernel versions containing the specified commit hashes and was published on April 17, 2024. No known exploits are currently reported in the wild, and no CVSS score has been assigned yet.

Potential Impact

For European organizations relying on Linux-based network infrastructure, especially those using Linux bridges with switchdev drivers and multicast snooping enabled, this vulnerability can cause persistent stale multicast group memberships in network hardware. This may lead to incorrect multicast traffic forwarding, resulting in network inefficiencies, potential data leakage, or denial of service for multicast-dependent applications such as IPTV, conferencing, or real-time data distribution. Enterprises operating data centers, telecom providers, or critical infrastructure that use Linux bridges for network segmentation and multicast management could experience degraded network performance or unintended multicast traffic exposure. The issue is particularly relevant for environments using hardware switches compatible with the affected drivers (e.g., Marvell mv88e6xxx series). While the vulnerability does not directly allow remote code execution or privilege escalation, the network misbehavior it causes can undermine network reliability and confidentiality of multicast streams. Given the widespread use of Linux in European enterprise and carrier networks, the impact could be significant in sectors dependent on multicast traffic integrity and isolation.

Mitigation Recommendations

European organizations should promptly apply the Linux kernel patches that address CVE-2024-26837 once available from their Linux distribution vendors or kernel maintainers. Specifically, ensure that the kernel version in use includes the fix that acquires the MDB write lock during replay list generation and checks for deferred replay events to prevent duplicates. Network administrators should audit their use of Linux bridges with multicast snooping and switchdev drivers, particularly on hardware platforms like Marvell mv88e6xxx, to identify vulnerable systems. Where immediate patching is not feasible, consider temporarily disabling multicast snooping on affected bridges to mitigate stale group membership issues, understanding this may increase multicast flooding. Additionally, validate bridge and port configurations after bridge deletions and port reassignments to detect and clear stale multicast entries manually if possible. Monitoring multicast traffic patterns for anomalies or unexpected forwarding behavior can help detect exploitation or impact. Finally, coordinate with hardware vendors to confirm compatibility and firmware updates that complement kernel fixes.