CVE-2026-43042

What it actually does

This is a Linux kernel memory-safety flaw in the MPLS subsystem. RCU-protected code paths such as MPLS route forwarding and route dumping can observe an inconsistent pair of MPLS platform-label state values while another thread resizes the platform label table under the platform mutex. That race can cause out-of-bounds kernel memory access. The most likely technical outcomes are kernel memory disclosure and kernel crash/panic, with impact to confidentiality and availability. Exploitation requires local access with the ability to exercise MPLS configuration or routing paths, typically through privileged networking capabilities such as CAP_NET_ADMIN or equivalent control over a network namespace.

Why it matters to the business

Systems running affected Linux kernels with MPLS enabled or available may be exposed to local denial-of-service or sensitive memory disclosure. In operational terms, a user or compromised workload with sufficient networking privileges could crash a host or potentially expose kernel memory. This is most important for multi-tenant Linux hosts, container platforms that delegate network administration capabilities, routing systems, NFV infrastructure, and environments where MPLS is actively used. The CVSS score is high, but EPSS is currently very low, the vulnerability is not listed in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized based on MPLS exposure and local privilege boundaries rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker first obtains local execution on a Linux system or in a network namespace with enough privilege to interact with MPLS networking state. The attacker then repeatedly changes MPLS platform label sizing while concurrently triggering code paths that read the label table, such as MPLS route forwarding or route dumping through netlink. Because the vulnerable kernel can read platform_labels and platform_label inconsistently during a concurrent resize, the attacker attempts to win the race and cause the kernel to index outside the valid MPLS label table. Successful exploitation can result in a kernel out-of-bounds access, which may disclose kernel memory through observable outputs or crash the kernel, interrupting workloads on the host.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding sequence-count protection around the MPLS platform label table snapshot. Because exact fixed package versions were not provided, use the fixed kernel releases or backported vendor kernel updates from the relevant Linux distribution or appliance vendor. If immediate patching is not possible, reduce exposure by disabling MPLS where it is not required, preventing automatic loading of MPLS modules, setting MPLS platform labels to 0 where operationally safe, and limiting local users, containers, or services that have CAP_NET_ADMIN or equivalent network configuration privileges. On container platforms, avoid granting broad network administration capabilities to untrusted workloads and review network namespace delegation controls.

How to confirm the fix worked

Confirm the running kernel version and vendor advisory status, then verify that the installed kernel package contains the MPLS seqcount fix for the platform_label/platform_labels race. Check whether MPLS is loaded or enabled by inspecting loaded modules, MPLS sysctls, and kernel configuration. Validate exposure reduction by confirming that untrusted users or containers cannot change net.mpls.platform_labels or add/delete MPLS routes. After patching and rebooting, confirm the system is running the updated kernel, not only that the package is installed. For assurance testing in non-production environments, exercise MPLS route add/delete, route dump, and platform label resize operations under concurrency and verify that no kernel warnings, KASAN reports, oopses, or panics occur.

Typical attack path

1. Gain local access to a Linux host or containerized environment with delegated network administration privileges.
2. Confirm that MPLS kernel support is present and that MPLS platform labels can be configured or resized.
3. Repeatedly resize the MPLS platform label table, commonly through the net.mpls.platform_labels sysctl or equivalent network configuration paths.
4. In parallel, trigger MPLS route dump or forwarding paths that read the platform label table.
5. Race the resize and read-side paths until the kernel observes inconsistent MPLS label-table state.
6. Use the resulting out-of-bounds access to cause a kernel crash or attempt to expose kernel memory.

How to detect it

Look for evidence of prior exploitation in kernel logs, audit logs, system journals, and EDR telemetry. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k, auditd records for sysctl and netlink route operations, container runtime audit logs showing privileged or CAP_NET_ADMIN workloads, and crash dump infrastructure such as kdump, apport, ABRT, or vmcore repositories. Investigate kernel oopses, panics, KASAN or UBSAN findings, and slab/out-of-bounds reports referencing MPLS functions such as mpls_forward, mpls_dump_routes, resize_platform_label_table, mpls_label_ok, mpls_route_add, or mpls_route_del. Also review bursts of changes to net.mpls.platform_labels, repeated MPLS route add/delete activity, or high-frequency RTM_GETROUTE/route dump activity occurring shortly before a crash. There are no known public exploitation-specific network indicators from the provided data; detection should focus on host artifacts and anomalous local MPLS configuration behavior.

• BUG: KASAN: out-of-bounds
• BUG: KASAN: slab-out-of-bounds
• general protection fault
• kernel BUG at net/mpls
• Oops:
• Kernel panic - not syncing
• mpls_forward
• mpls_dump_routes
• resize_platform_label_table
• mpls_label_ok
• mpls_route_add
• mpls_route_del
• net.mpls.platform_labels
• /proc/sys/net/mpls/platform_labels
• RTM_GETROUTE
• RTM_NEWROUTE
• RTM_DELROUTE
• mpls_router
• mpls_iptunnel

What your security team should do

• Inventory Linux systems where MPLS is enabled, MPLS modules are loaded, or net.mpls.platform_labels is nonzero.
• Prioritize patching for routing hosts, NFV systems, Kubernetes/container hosts, and multi-user systems where CAP_NET_ADMIN may be delegated.
• Apply the vendor kernel update containing the MPLS platform label seqcount fix and reboot into the fixed kernel.
• If patching is delayed, disable MPLS where not needed and restrict loading of MPLS-related kernel modules.
• Review container and service permissions for CAP_NET_ADMIN, privileged containers, and host network access; remove these privileges unless strictly required.
• Monitor kernel logs for MPLS-related crashes, KASAN reports, out-of-bounds access warnings, and unexpected host reboots.
• Treat suspicious local attempts to repeatedly modify MPLS labels or dump MPLS routes as potential exploitation or probing activity.