CVE-2026-43035

What it actually does

This Linux kernel flaw is a local information disclosure in the traffic control scheduler netlink API. When tc_chain_fill_node() builds a netlink response, the tcm_info field in struct tcmsg is not initialized before the message is copied back to userspace. Because the backing kernel allocation is not zeroed, a local user able to query traffic-control chain information can receive 4 bytes of stale kernel heap memory per response. The bug does not directly provide code execution or privilege escalation, but kernel memory disclosure can be useful as an exploit-chain primitive, for example to reduce uncertainty about heap contents or help bypass kernel hardening in combination with another vulnerability.

Why it matters to the business

The direct business risk is limited but not negligible: a local attacker or compromised low-privilege workload may be able to extract small fragments of kernel memory and use them to support a broader kernel attack. This is most relevant for multi-user Linux systems, container hosts, shared compute platforms, and environments where untrusted users can create network namespaces or obtain CAP_NET_ADMIN in a namespace. EPSS is very low, there is no known KEV listing, no ransomware association, and no reported public exploit maturity, so emergency internet-facing response is not indicated; however, Linux kernel prevalence means normal kernel patch cycles should include this fix broadly.

How an attack unfolds

An attacker first needs local access to an affected Linux system and enough permission to interact with traffic-control chain netlink operations, commonly through CAP_NET_ADMIN in a network namespace. In environments that allow unprivileged user namespaces, an attacker may be able to create a user and network namespace where they hold the needed namespace-scoped capability. The attacker then sends crafted rtnetlink requests to dump or query traffic-control chain information. During response construction, the vulnerable kernel path fills most fields of struct tcmsg but leaves tcm_info uninitialized. The kernel copies the response to userspace, leaking 4 bytes of stale kernel heap data. By repeating the operation and manipulating heap layout, an attacker may attempt to collect useful memory fragments. The leak is small and not directly destructive, but it can assist later-stage exploitation of a separate kernel memory-corruption flaw.

How to fix it

Upgrade to a Linux kernel build that includes the fix for net/sched/cls_api.c where tc_chain_fill_node() explicitly initializes tcm_info to zero. Because no exact fixed package versions were provided, use the security advisory or changelog from the relevant Linux distribution or kernel vendor and confirm the backported fix is present; do not rely only on upstream version numbers. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_NET_ADMIN to trusted workloads only, disabling or tightly controlling unprivileged user namespaces where operationally feasible, preventing untrusted containers from creating network namespaces with elevated networking capabilities, and applying container runtime/seccomp/AppArmor/SELinux policies that block unnecessary traffic-control and rtnetlink operations. Reboot into the fixed kernel after installation; installing a kernel package alone is insufficient if the running kernel has not changed.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not just the installed package inventory. Check uname -r and compare it to the distribution advisory for this issue, then confirm the active kernel package changelog includes the traffic-control cls_api fix that zeroes tcm_info in tc_chain_fill_node(). If source or debug symbols are available, verify the patched code path initializes tcm_info before netlink message publication. For exposure validation, identify systems where untrusted users, containers, or services can obtain CAP_NET_ADMIN or create user/network namespaces, because those systems are more likely to be practically reachable. A functional test can be built by repeatedly issuing traffic-control chain netlink dump requests and confirming tcm_info is consistently zeroed in responses, but this should be performed only in controlled test environments because legitimate traffic-control state and kernel backports vary by distribution.

Typical attack path

1. Gain local code execution as a low-privileged user or inside a workload on an affected Linux host.
2. Obtain the ability to issue traffic-control netlink requests, such as CAP_NET_ADMIN in the initial network namespace or in a newly created network namespace if unprivileged namespaces are allowed.
3. Create or interact with traffic-control chain objects using rtnetlink/tc interfaces.
4. Send repeated chain dump/query requests that reach tc_chain_fill_node().
5. Read returned netlink messages and extract the uninitialized 4-byte tcm_info field.
6. Correlate leaked bytes across repeated requests and, if useful, combine the disclosure with another kernel vulnerability or hardening bypass technique.

How to detect it

There are no reliable standalone indicators that this issue has already been exploited because the leak occurs inside legitimate local netlink responses and typically leaves no file, process, or network artifact. Detection should focus on behavioral evidence around attempts to exercise traffic-control netlink paths from unexpected users or workloads. Useful sources include auditd execve records for tc or custom tooling, shell history on multi-user systems, container runtime logs showing unusual CAP_NET_ADMIN grants, namespace creation telemetry, eBPF/netlink monitoring if deployed, and EDR telemetry for repeated traffic-control operations by non-administrative accounts. Look for unexpected use of tc chain/filter commands, frequent creation of user and network namespaces, or local programs issuing RTM_GETCHAIN-style rtnetlink requests. Because exploitation may be performed through custom binaries and the returned data is only 4 bytes per response, absence of such logs does not prove non-exploitation. Investigations should correlate suspicious local enumeration or namespace activity with other kernel exploit attempts, crashes, privilege changes, or anomalous capability use.

What your security team should do

• Patch affected Linux kernels through normal security maintenance and prioritize shared, multi-tenant, container-hosting, developer, CI/CD, and high-density compute systems.
• Verify that systems have rebooted into the fixed kernel after patch deployment.
• Inventory where CAP_NET_ADMIN is granted to containers, services, or users, and remove it wherever it is not strictly required.
• Review whether unprivileged user namespaces are enabled; disable or constrain them on systems that do not require them.
• Add hardening controls for container hosts, including seccomp, AppArmor, SELinux, and runtime policies that restrict unnecessary tc/rtnetlink operations.
• Treat this primarily as a kernel exploit-chain primitive; investigate it alongside any signs of local privilege-escalation attempts rather than as a standalone remote compromise indicator.
• Monitor vendor advisories for exact backported fixed versions and update patch baselines when distribution-specific package versions become available.