CVE-2026-43457

What it actually does

This vulnerability is a memory leak in the Linux kernel MCTP-over-I2C receive path. When an MCTP I2C device has receive handling disabled, the kernel allocates a socket buffer for an incoming message but fails to free it because the packet is not passed to the normal network receive path. Repeated triggering can steadily consume kernel memory, particularly sk_buff-related memory, until the system experiences memory pressure, degraded performance, or a denial of service. The flaw does not provide direct confidentiality or integrity impact and is not known to enable code execution or privilege escalation.

Why it matters to the business

A local, low-privileged attacker with access to the affected MCTP/I2C interface could cause an affected Linux system to become unstable or unavailable by exhausting kernel memory. The most likely operational consequence is disruption of servers, embedded systems, appliances, or management-controller-adjacent Linux deployments that use MCTP over I2C. The CVSS availability impact is high, but the practical urgency is moderated by the local-access requirement, low EPSS score, lack of known exploitation, and absence from the CISA KEV catalog.

How an attack unfolds

An attacker first needs local access to a Linux system where the affected kernel code is present and MCTP over I2C is enabled or reachable. The attacker then causes MCTP I2C traffic to reach the receive path while the relevant device receive flag is disabled. In the vulnerable condition, each received packet can cause the kernel to allocate an skb that is not later consumed by netif_rx() and is not explicitly freed. By repeatedly triggering this path, the attacker causes kernel memory consumption to grow over time. If sustained, the system may enter memory pressure, trigger OOM behavior, degrade network or device functionality, or require rebooting to restore normal service. No public exploit maturity or active threat actor exploitation is currently indicated for this CVE.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the MCTP I2C receive-path skb leak. Because no exact fixed version was provided, use the latest supported kernel from the operating system or appliance vendor and verify that the vendor advisory includes the fix for this issue. Where immediate patching is not possible, reduce exposure by disabling unused MCTP-over-I2C functionality, removing or blacklisting unneeded MCTP/I2C-related kernel modules where operationally safe, restricting local shell access, and limiting access to interfaces or device nodes that allow untrusted users to influence MCTP I2C traffic. Rebooting may be required after kernel update installation for the fix to take effect.

How to confirm the fix worked

Confirm the running kernel version is the vendor-fixed version or contains the upstream patch that frees the skb when MCTP I2C receive is disabled. Validate with vendor package metadata, kernel changelogs, or source inspection for the corrected receive-path cleanup behavior. On running systems, check whether MCTP-related modules and interfaces are present and whether MCTP over I2C is actually enabled. After remediation, repeat any safe internal reproduction or regression test and confirm that skb/slab memory usage does not grow unbounded when MCTP I2C receive traffic is generated under the previously vulnerable condition. Also verify that the system has been rebooted into the updated kernel rather than merely having the package installed.

Typical attack path

1. Obtain local, low-privileged access to an affected Linux system.
2. Identify that the system is running a vulnerable kernel with MCTP over I2C support available or enabled.
3. Trigger MCTP I2C receive activity while the device receive path is disabled.
4. Repeat the triggering condition to leak one or more sk_buffs per receive event.
5. Continue until kernel memory pressure causes service degradation, OOM events, system instability, or denial of service.

How to detect it

Look for evidence of denial-of-service behavior rather than a reliable exploit signature. Relevant sources include kernel logs, system journals, OOM killer logs, audit logs for local user activity, hardware-management or platform logs, and monitoring telemetry for memory and slab allocator usage. Investigate unexplained increases in sk_buff or network-related slab caches, sustained kernel memory pressure, OOM killer activity, soft lockups, or sudden reboots on systems where MCTP over I2C is enabled. Correlate these events with local logins, privilege changes, execution of custom tooling, unusual access to device interfaces, or bursts of MCTP/I2C-related activity. There are no known public threat actors or ransomware campaigns associated with this issue, and no specific exploit strings are currently known.

What your security team should do

• Prioritize patching systems that expose or rely on MCTP over I2C, including embedded Linux systems, appliances, hardware-management platforms, and servers with relevant kernel support enabled.
• Upgrade to the latest vendor-supported kernel that includes the fix, then reboot and verify the active kernel version.
• Inventory systems with MCTP, I2C, or related kernel modules enabled to determine practical exposure.
• If patching is delayed, disable unused MCTP/I2C functionality or restrict local access paths that could trigger the vulnerable receive path.
• Monitor affected systems for unexplained kernel memory growth, skb/slab growth, OOM events, and reboots until patched.
• Treat exploitation likelihood as currently low because EPSS is very low, no public exploit maturity is reported, and the issue is not in CISA KEV; still remediate because successful exploitation can cause high availability impact.