CVE-2026-97436 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
dpaa2-switch: rework FDB management on the bridge leave path
On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one.
The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB.
Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified within the Linux kernel's dpaa2-switch driver stems from an incorrect implementation of Forwarding Database management during network interface state transitions, specifically when a port leaves a software bridge. The Data Path Acceleration Engine 2 switch hardware relies on distinct Forwarding Databases to isolate traffic between different bridged networks or standalone interfaces. In the original logic, whenever a port was removed from a bridge configuration via the dpaa2_switch_port_set_fdb function, the driver unconditionally attempted to allocate a new FDB for that port if no existing suitable database was found. This approach assumed a one-to-one mapping between ports and independent forwarding contexts without accounting for shared resources across multiple bridges on the same DPSW instance.
The core technical flaw occurs in scenarios where multiple bridges share interfaces from the same physical switch hardware. When the final port belonging to Bridge One departs, the driver identifies an unused FDB allocated for that bridge context and assigns it to the departing port. However, the code fails to mark this previously active FDB as available or freed within the bridge's internal tracking structures. Consequently, while the departing port moves to a new database, the original FDB remains logically occupied but effectively orphaned from its intended scope. As more ports leave bridges under these conditions, the system exhausts the limited pool of hardware FDBs because they are not properly recycled or marked as free for reuse by other active bridge contexts.
This resource management error leads to a state where multiple distinct network interfaces end up sharing the same Forwarding Database due to allocation failures and subsequent fallback behaviors. When the limit of available FDBs is reached, new ports may be forced into existing databases rather than receiving isolated ones. This results in severe traffic leakage between networks that should remain segregated, effectively bypassing layer two isolation mechanisms. The operational impact includes potential unauthorized network access, data exfiltration across security zones, and denial of service conditions as the switch hardware becomes unable to process new bridging configurations due to resource exhaustion.
From a classification perspective, this issue aligns with CWE-401, which describes missing release of memory or other resources after use, specifically manifesting here as improper resource management leading to state corruption. In terms of attack vectors and tactical implications, the ability to merge isolated network segments could facilitate lateral movement within a segmented environment, relating to ATT&CK techniques involving network service discovery or unauthorized access via shared infrastructure. The vulnerability highlights critical risks in embedded systems where hardware resources are constrained and software logic must precisely mirror physical constraints.
The resolution involves reworking the FDB allocation strategy on the bridge leave path to ensure strict adherence to resource lifecycle management. Instead of blindly allocating a new database for every departing port, the updated logic first determines whether the current port is the last one remaining in its specific bridge context. If it is indeed the final port leaving that bridge, the driver retains the existing FDB assignment rather than seeking an alternative, thereby preserving the isolation boundary without consuming additional resources. Furthermore, if other ports remain within the original bridge, a new allocation proceeds as before, but crucially, the old FDB associated with the departing context is now correctly marked as unused and available for future assignments by remaining or subsequent bridges. This fix ensures that hardware forwarding databases are properly recycled, maintaining network segmentation integrity and preventing resource exhaustion attacks.