CVE-2026-43025

What it actually does

This is a Linux kernel memory-safety flaw in the netfilter conntrack netlink expectation path. When userspace creates a new conntrack expectation and supplies an explicit helper that differs from the master conntrack helper, validation can use the wrong helper context while processing expectation class data, resulting in a slab out-of-bounds read in nf_ct_expect_related_report(). A local user with sufficient privilege to interact with netfilter/conntrack netlink interfaces, typically CAP_NET_ADMIN in the relevant network namespace, may be able to read adjacent kernel memory or trigger a kernel crash. The primary impacts are kernel information disclosure and denial of service, with limited integrity impact depending on how leaked memory or corrupted validation state can be used in a chained attack.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local privilege-bound attacks that can disclose sensitive kernel memory or crash the host. The operational risk is highest on multi-user Linux systems, container hosts, Kubernetes nodes, CI runners, network appliances, and platforms that delegate network administration capabilities into containers or untrusted workloads. Although the EPSS is very low, there is no known public exploit maturity, and it is not listed in CISA KEV, kernel memory bugs can become more serious when chained with other vulnerabilities, so patching should be prioritized during normal kernel maintenance windows and accelerated where untrusted users or containers have network administration privileges.

How an attack unfolds

An attacker first needs local execution on a vulnerable Linux system with permission to use netfilter conntrack netlink operations, commonly through CAP_NET_ADMIN in the host or a network namespace. The attacker opens a NETLINK_NETFILTER socket and crafts a ctnetlink message to create a new conntrack expectation. The malicious request supplies expectation attributes that include a helper name or helper-related metadata inconsistent with the existing master conntrack helper, along with expectation class data that drives validation down the vulnerable path. The kernel processes the request in ctnetlink_new_expect() and ctnetlink_create_expect(), then reaches nf_ct_expect_related_report(), where it reads beyond the expected slab object boundary. Depending on kernel configuration and surrounding heap contents, the result may be leaked kernel memory returned or exposed through netlink behavior, a KASAN-detected fault on debug kernels, or a production kernel crash/panic causing denial of service. Practical exploitation is local and capability-dependent, and may be most relevant in environments where containers or sandboxed workloads are granted CAP_NET_ADMIN.

How to fix it

Upgrade to a Linux kernel version that contains the netfilter ctnetlink fix that ignores explicit userspace-supplied helpers on new expectations and uses the existing master conntrack helper instead. Because no package-specific fixed versions were provided, obtain fixed kernel builds from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel stable branch advisory. After installing the updated kernel package, reboot into the fixed kernel and remove or de-prioritize vulnerable older kernels where operationally possible. As interim mitigations, restrict CAP_NET_ADMIN and other network-administration capabilities to trusted users and workloads only, avoid granting privileged or NET_ADMIN-enabled containers to untrusted tenants, disable unneeded conntrack helper functionality where feasible, and enforce container/runtime policies that prevent untrusted workloads from accessing netfilter administration paths.

How to confirm the fix worked

Confirm exposure by inventorying Linux kernel versions across servers, container hosts, appliances, and images, then comparing them against vendor advisories for this issue. Validate remediation by confirming the running kernel, not only the installed package, is the fixed version after reboot using commands such as uname -a and package-manager kernel queries. Where source or vendor patches are available, verify the ctnetlink expectation logic no longer trusts a userspace-supplied helper for new expectations and instead derives the helper from the master conntrack entry. Review capability assignments for users, services, and containers to confirm untrusted workloads do not have CAP_NET_ADMIN. On test systems only, a controlled proof-of-concept should no longer produce KASAN slab-out-of-bounds reports or kernel crashes in nf_ct_expect_related_report().

Typical attack path

1. Obtain local code execution on a Linux system running an affected kernel.
2. Gain or already possess permission to interact with netfilter conntrack netlink APIs, such as CAP_NET_ADMIN in a network namespace.
3. Open a NETLINK_NETFILTER socket from userspace.
4. Create or identify a master conntrack entry associated with a helper.
5. Send a crafted ctnetlink new-expectation message with helper-related attributes that differ from the master conntrack helper and include expectation class data.
6. Trigger the vulnerable kernel path through ctnetlink_new_expect(), ctnetlink_create_expect(), and nf_ct_expect_related_report().
7. Use the resulting out-of-bounds read for kernel memory disclosure, or repeatedly trigger the condition to crash the kernel and cause denial of service.

How to detect it

Look for evidence of prior exploitation in kernel logs, crash dumps, audit records, and container/runtime telemetry. Key sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore analysis, auditd syscall and capability logs, container runtime events, Kubernetes audit logs, and EDR telemetry for processes using netlink sockets with network administration capability. Suspicious artifacts include KASAN slab-out-of-bounds reports in nf_ct_expect_related_report(), kernel oops or panic events during ctnetlink expectation creation, repeated failures or crashes involving nfnetlink/netfilter conntrack, and unexpected local processes or containers with CAP_NET_ADMIN sending NETLINK_NETFILTER messages. In container environments, correlate crash timing with privileged pods, pods using hostNetwork, containers granted NET_ADMIN, or workloads that recently invoked conntrack, iptables, nftables, or custom netlink tooling. Absence of these logs does not prove non-exploitation because production kernels may not include KASAN and an out-of-bounds read may not always crash.

• BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report
• nf_ct_expect_related_report
• ctnetlink_create_expect
• ctnetlink_new_expect
• nfnetlink_rcv_msg
• netlink_rcv_skb
• CTA_EXPECT_CLASS
• CTA_EXPECT_HELP_NAME
• NETLINK_NETFILTER
• CAP_NET_ADMIN
• kernel BUG at net/netfilter
• KASAN: slab-out-of-bounds
• general protection fault in nf_ct_expect_related_report
• kernel panic - not syncing

What your security team should do

• Identify all Linux systems and container hosts running kernels that may include the vulnerable netfilter ctnetlink expectation code.
• Prioritize patching for multi-tenant systems, Kubernetes/container nodes, CI/CD runners, network appliances, bastion hosts, and any environment where untrusted users or workloads may hold CAP_NET_ADMIN.
• Schedule kernel updates and reboots through the standard change process; accelerate remediation for systems that allow privileged containers or delegated network namespaces.
• Audit container, orchestration, and sudo policies for CAP_NET_ADMIN, privileged mode, host networking, and access to netfilter administration interfaces; remove these permissions wherever they are not strictly required.
• Monitor kernel logs for KASAN, BUG, oops, panic, or stack traces involving nf_ct_expect_related_report, ctnetlink_create_expect, or ctnetlink_new_expect.
• Treat unexplained kernel crashes involving netfilter conntrack expectation code as potentially security-relevant and preserve logs, crash dumps, and recent process/audit activity.
• Because the issue is not currently in CISA KEV, not known to be ransomware-used, and has low EPSS, align broad remediation with kernel patch cycles while applying risk-based urgency to exposed multi-user or containerized platforms.