CVE-2026-43205

What it actually does

This is a local Linux kernel memory-corruption flaw in the dpaa2-switch driver. The driver trusts a firmware-reported interface count, sw_attr.num_ifs, without validating it against the fixed maximum DPSW_MAX_IF value of 64. That value is later used to populate a fixed-size if_id array during flood-configuration handling. If firmware reports 64 or more interfaces, or exactly 64 when the driver appends the control interface, the driver can write past the end of the array. Successful exploitation can corrupt kernel memory, potentially causing a kernel crash, denial of service, privilege escalation, or arbitrary kernel-code execution depending on memory layout, kernel hardening, and attacker control over the corrupted data.

Why it matters to the business

Systems running affected Linux kernels on hardware that uses the dpaa2-switch driver may be exposed to local denial-of-service or privilege-escalation risk. The most likely operational impact is instability or crashes on network appliances, embedded systems, edge devices, or servers using NXP DPAA2 switching components. There is currently no CISA KEV listing, no known ransomware association, no public exploit maturity reported, and EPSS is very low and flat, so broad internet-scale exploitation is unlikely; however, affected kernel-space networking components should still be patched because successful exploitation can compromise the host or disrupt network availability.

How an attack unfolds

An attacker first needs local access to an affected system or another position that allows them to influence the DPAA2 switch device state, firmware response, or driver code path. They then cause the dpaa2-switch driver to initialize or query switch attributes where firmware reports a num_ifs value of 64 or greater. When the driver later builds flood configuration, dpaa2_switch_fdb_get_flood_cfg() iterates over the unvalidated interface count and writes port identifiers into a fixed-size array. In the boundary case where num_ifs equals 64 and all ports match the flood filter, the array is filled and the control interface is written one element past the end. That out-of-bounds write corrupts adjacent kernel memory. Depending on what memory is overwritten, the result may be an immediate kernel panic, a controlled denial of service, or a path toward local privilege escalation. Exploitation is constrained by the need for local access and relevant DPAA2 hardware/driver exposure.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution, vendor, or long-term stable branch that includes the dpaa2-switch fix validating sw_attr.num_ifs in dpaa2_switch_init(). No exact fixed package versions were provided, so use vendor security advisories and kernel changelogs to confirm inclusion of the patch for CVE-2026-43205 or the upstream fix described as validating num_ifs against DPSW_MAX_IF. Where immediate patching is not possible, reduce exposure by disabling or unloading the dpaa2-switch driver if the hardware/functionality is not required, restricting local shell access, limiting administrative access to DPAA2 management utilities, and applying kernel hardening features such as lockdown, module signing, and least-privilege device access. Embedded and appliance vendors should also validate bundled firmware behavior and ship kernel updates containing the bounds check.

How to confirm the fix worked

Confirm exposure by checking whether the system runs a kernel version or vendor kernel package that predates the dpaa2-switch bounds-check fix and whether the dpaa2-switch module is present or loaded. Use commands such as uname -a, modinfo dpaa2-switch, lsmod | grep dpaa2, and vendor package inventory tooling to identify affected deployments. Confirm remediation by verifying that the running kernel package includes the fix, not only that a patched package is installed. Reboot into the patched kernel where required. On test systems with suitable DPAA2 hardware, validate that initialization rejects num_ifs values greater than or equal to DPSW_MAX_IF rather than proceeding into flood-configuration logic. Also review kernel logs after update for absence of dpaa2-switch crashes, KASAN reports, slab out-of-bounds messages, or general protection faults tied to dpaa2_switch_fdb_get_flood_cfg().

Typical attack path

1. Identify a Linux system using an affected kernel with the dpaa2-switch driver present and active.
2. Obtain local low-privileged access or another ability to influence DPAA2 switch firmware attributes or switch configuration state.
3. Cause firmware or the device-management path to return a sw_attr.num_ifs value of 64 or greater.
4. Trigger dpaa2-switch flood-configuration handling, such as FDB flood configuration retrieval or related switch setup logic.
5. Force the driver to write more interface IDs than fit in the fixed cfg->if_id array.
6. Use the resulting kernel memory corruption to crash the system or attempt privilege escalation.

How to detect it

Look for evidence of kernel memory corruption or crashes involving the dpaa2-switch driver. Primary log sources include kernel ring buffer output, system journal, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, KASAN reports, and appliance diagnostic bundles. Search for panics, general protection faults, slab out-of-bounds reports, or stack traces containing dpaa2_switch_fdb_get_flood_cfg(), dpaa2_switch_init(), dpsw_get_attributes(), or dpaa2-switch. Because exploitation requires local access or control over device/firmware behavior, correlate any kernel crash with recent local logins, privilege changes, execution of network management utilities, firmware updates, device reset events, or unusual switch/FDB configuration activity. There are no public exploit-specific network indicators; detection should focus on host telemetry, kernel crash artifacts, and suspicious local activity preceding a dpaa2-switch fault.

• dpaa2-switch
• dpaa2_switch_fdb_get_flood_cfg
• dpaa2_switch_init
• dpsw_get_attributes
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: unable to handle kernel
• general protection fault
• kernel panic
• Oops:
• cfg->if_id
• DPSW_MAX_IF
• sw_attr.num_ifs

What your security team should do

• Prioritize patching affected Linux kernels on systems using NXP DPAA2 switching hardware or the dpaa2-switch driver, especially network appliances, edge platforms, and embedded Linux devices.
• Inventory systems for the dpaa2-switch module and DPAA2 hardware before treating the vulnerability as broadly applicable across all Linux hosts.
• If patching is delayed, disable or blacklist dpaa2-switch where it is not operationally required.
• Restrict local user access and administrative access to network-switch management functions on affected systems.
• Monitor kernel logs for crashes, KASAN findings, or panic traces referencing dpaa2-switch, dpsw_get_attributes, or dpaa2_switch_fdb_get_flood_cfg.
• Track vendor kernel advisories because fixed versions vary by Linux distribution, appliance vendor, and kernel branch.
• Do not rely on the low EPSS score alone for affected appliances; local kernel privilege-escalation flaws can still be high impact in shared, edge, or operational technology environments.