CVE-2026-43116

What it actually does

This is a race condition in the Linux kernel netfilter conntrack netlink expectation handling. Certain ctnetlink expectation operations can access exp->master after the associated master conntrack object has been freed, creating a use-after-free condition in kernel memory. A successful attacker with local access and the required netfilter/netlink privileges could potentially trigger kernel memory corruption, leading to privilege escalation, information disclosure, or a kernel crash. The CVSS vector indicates local, low-privilege exploitation with no user interaction, but practical exploitation likely depends on access to NETLINK_NETFILTER operations, commonly gated by CAP_NET_ADMIN in a network namespace.

Why it matters to the business

An attacker who already has limited local access to a Linux system, container, or network namespace may be able to escalate privileges or crash the host kernel. This can affect server availability, container isolation, and workload trust boundaries. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a very low EPSS score, so urgency is lower than internet-exposed remote-code-execution flaws; however, Linux kernel privilege-escalation bugs should still be remediated promptly on multi-user systems, container hosts, CI/CD runners, and shared infrastructure.

How an attack unfolds

An attacker first obtains local code execution on a Linux system or inside an environment where they can interact with netfilter conntrack netlink functionality, such as a container or network namespace with CAP_NET_ADMIN. They open a NETLINK_NETFILTER socket and issue conntrack expectation operations, such as add, get, delete, or event-triggering operations, while concurrently causing the master conntrack entry associated with an expectation to be removed. Due to insufficient synchronization, the kernel can continue to use the expectation's master conntrack pointer after the master object has gone away. By repeatedly racing these operations, the attacker may trigger a use-after-free. In a simple case this causes a kernel oops or panic, producing denial of service. With reliable heap grooming and kernel exploit development, the same primitive may be used to corrupt kernel memory and escalate privileges. No known exploitation, ransomware use, or KEV listing is indicated in the supplied intelligence.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the netfilter ctnetlink fix for safe access to master conntrack objects. Because no exact fixed package versions were provided, use vendor advisories and kernel changelogs to identify the first fixed kernel for each supported branch. Prioritize updates on multi-tenant Linux hosts, container platforms, systems that allow unprivileged user namespaces, and workloads granted CAP_NET_ADMIN. If immediate patching is not possible, reduce exposure by removing CAP_NET_ADMIN from containers and untrusted workloads, disabling or restricting unprivileged user namespaces where operationally feasible, limiting local shell access, preventing untrusted users from creating network namespaces, and unloading or disabling unused nf_conntrack_netlink/netfilter conntrack functionality where it is not required. Treat mitigations as defense-in-depth only; the durable fix is a patched kernel followed by a reboot into that kernel.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version after reboot and comparing it with the vendor-fixed version or advisory. Review the distribution kernel changelog for references to this CVE, netfilter, ctnetlink, conntrack expectation locking, nf_conntrack_expect_lock, or safe access to master conntrack. Verify that vulnerable systems no longer boot into older kernels retained by the package manager or bootloader. Validate exposure reduction by confirming untrusted containers do not run with CAP_NET_ADMIN, unprivileged user namespace policy matches organizational requirements, and unnecessary nf_conntrack_netlink functionality is not loaded. Where kernel live patching is used, confirm the live patch explicitly covers this netfilter conntrack issue.

Typical attack path

1. Gain local code execution on a Linux system, container host, or namespace-enabled workload.
2. Obtain the ability to interact with netfilter conntrack netlink operations, typically through CAP_NET_ADMIN in a relevant network namespace.
3. Create or manipulate conntrack expectations associated with a master conntrack entry.
4. Concurrently delete, expire, or otherwise cause the master conntrack object to be released while expectation get/delete/event paths are processing.
5. Trigger the race so the kernel dereferences a stale exp->master pointer.
6. Use the resulting kernel memory corruption to crash the system or, with additional exploit primitives, escalate privileges.

How to detect it

There are no unique network indicators for this vulnerability because exploitation is local and occurs through kernel netlink interfaces. To determine whether exploitation may have occurred, review kernel logs, crash dumps, audit logs, and endpoint telemetry for signs of kernel memory corruption or suspicious local netfilter activity. Useful log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, kdump/vmcore artifacts, auditd records for capability and namespace activity, container runtime logs, and EDR process telemetry. Look for kernel oops, panic, KASAN, KFENCE, or general protection fault reports mentioning netfilter, ctnetlink, nfnetlink, nf_conntrack, nf_conntrack_expect, or conntrack expectation paths. Also investigate unexpected local processes using tools such as conntrack, nft, iptables, unshare, nsenter, or custom binaries shortly before a crash, especially when combined with CAP_NET_ADMIN or network namespace creation. Absence of these artifacts does not prove non-exploitation, because a successful privilege escalation may not leave a vulnerability-specific log entry.

• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• general protection fault
• kernel BUG at net/netfilter
• RIP: ctnetlink
• RIP: nf_ct_expect
• RIP: nf_conntrack
• nf_conntrack_expect
• ctnetlink
• nfnetlink
• NETLINK_NETFILTER
• conntrack -E expect
• conntrack -L expect
• conntrack -D expect
• CAP_NET_ADMIN
• unshare -n
• nsenter --net
• /proc/net/nf_conntrack
• /proc/net/ip_conntrack
• nf_conntrack_netlink

What your security team should do

• Inventory Linux systems, container hosts, Kubernetes nodes, CI runners, and shared shell hosts running affected kernel branches.
• Prioritize patching systems where untrusted users or workloads can obtain CAP_NET_ADMIN, create network namespaces, or run privileged containers.
• Remove CAP_NET_ADMIN and privileged-container settings from workloads that do not strictly require them.
• Disable or restrict unprivileged user namespaces where compatible with business requirements.
• Monitor kernel logs for crashes, KASAN reports, general protection faults, or oops traces involving netfilter, ctnetlink, nfnetlink, or conntrack expectation code.
• Review audit logs for suspicious namespace creation, capability use, or unexpected local tooling interacting with NETLINK_NETFILTER.
• Keep older kernels unavailable for normal boot after patching to prevent rollback to a vulnerable kernel.