CVE-2026-43027

What it actually does

This is a Linux kernel netfilter connection-tracking helper use-after-free. When a conntrack helper is unregistered, stale expectation objects that still reference that helper may not be cleaned up correctly. After the helper object is freed, later expectation enumeration or packet-driven connection tracking can dereference the freed pointer. A local attacker with sufficient netfilter/netlink privileges may be able to crash the kernel or potentially achieve kernel-level code execution, resulting in confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation can cause host instability, denial of service, or potential local privilege escalation to kernel/root-level control. The issue is most relevant on Linux systems where untrusted users, workloads, or containers can obtain network administration privileges, such as through CAP_NET_ADMIN, privileged containers, or permissive user/network namespace settings. EPSS is currently very low and there is no known CISA KEV listing or public exploit maturity reported, but the high CVSS impact means exposed multi-user and container-hosting systems should still be prioritized for patching.

How an attack unfolds

An attacker first needs local execution and the ability to interact with netfilter conntrack helper configuration, typically requiring CAP_NET_ADMIN in a relevant network namespace or equivalent privileges. The attacker creates or manipulates conntrack helper state so that expectation entries reference a helper object. They then trigger helper unregistration through nfnetlink cthelper deletion. Due to the cleanup bug, the expectations may survive while still pointing to the freed helper. The attacker then causes the kernel to access those stale expectations, for example by dumping conntrack expectations through procfs/netlink or by sending traffic that drives connection tracking. This dereferences freed kernel memory and can produce a kernel oops/panic; with heap shaping and reliable primitives, the same condition may be investigated for local privilege escalation.

How to fix it

Apply the Linux kernel fix from the relevant distribution or kernel vendor as soon as available. The corrected code passes the actual helper pointer into expectation cleanup so expectations referencing the helper are destroyed before the helper object is freed. Because no exact fixed package versions were provided, track vendor advisories for the affected Linux kernel builds and update to the first kernel release or backported security update that includes the netfilter nf_conntrack_helper unregister cleanup fix. Reboot after installing the fixed kernel. As interim mitigation, avoid granting CAP_NET_ADMIN to untrusted users or containers, remove privileged container access where possible, disable unprivileged user namespaces if they allow untrusted users to create network namespaces with effective network administration capabilities, and unload or avoid unnecessary netfilter conntrack helper functionality/modules where operationally feasible.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not only that an updated package is installed; verify with uname -a and the distribution package manager after reboot. Check vendor changelogs for a fix referencing netfilter, nf_conntrack_helper, cthelper unregister, expectation cleanup, or use-after-free. On source-based or custom kernels, confirm the helper unregister path passes the helper pointer to expectation cleanup rather than NULL. Review whether the system exposes the vulnerable feature set by checking for loaded/available modules such as nf_conntrack, nf_conntrack_netlink, nfnetlink, and conntrack helper modules. Validate mitigations by ensuring untrusted workloads do not have CAP_NET_ADMIN, privileged container mode is not used unnecessarily, and unprivileged user namespace creation is restricted where appropriate.

Typical attack path

1. Gain local code execution on a Linux system.
2. Obtain netfilter administration capability, commonly CAP_NET_ADMIN in a network namespace, privileged container access, or equivalent local privilege.
3. Create or manipulate nf_conntrack helper and expectation state.
4. Delete or unregister the conntrack helper through nfnetlink cthelper handling.
5. Leave stale expectation objects referencing the freed helper object.
6. Trigger access to the stale expectation, such as by reading expectation dumps or sending packets that invoke connection tracking.
7. Cause a kernel use-after-free, resulting in crash or possible kernel-level privilege escalation.

How to detect it

To determine whether this was already exploited, review kernel logs, crash dumps, audit logs, and container/runtime telemetry for suspicious use of netfilter conntrack helper functionality followed by kernel memory errors or crashes. Relevant log sources include dmesg, journald/kern.log, /var/log/messages, /var/log/kern.log, crash/kdump vmcores, auditd syscall records, EDR process telemetry, container runtime events, and orchestration audit logs showing privileged containers or CAP_NET_ADMIN grants. Look for kernel oops, panic, KASAN, UBSAN, or slab use-after-free reports with call traces mentioning exp_seq_show, nf_conntrack expectations, nf_conntrack_helper_unregister, nfnl_cthelper_del, seq_read_iter, or proc_reg_read. Also review commands or processes accessing /proc/net/nf_conntrack_expect, /proc/net/netfilter/nfnetlink_queue, conntrack tooling, or nfnetlink sockets shortly before a crash. Absence of these artifacts does not prove non-exploitation, because successful local privilege escalation may not leave a distinctive log entry unless it causes a visible kernel fault.

• BUG: KASAN: slab-use-after-free
• slab-use-after-free in string
• exp_seq_show
• nf_conntrack_helper_unregister
• nfnl_cthelper_del
• nf_ct_expect_iterate_destroy
• /proc/net/nf_conntrack_expect
• /proc/net/stat/nf_conntrack
• nf_conntrack_expect
• nf_conntrack_helper
• nf_conntrack_netlink
• nfnetlink_cthelper
• NETLINK_NETFILTER
• conntrack -L expect
• conntrack -D expect
• CAP_NET_ADMIN

What your security team should do

• Prioritize kernel updates on multi-user Linux systems, container hosts, Kubernetes nodes, bastion hosts, and other systems where local users or workloads may obtain network administration privileges.
• Identify and reduce use of CAP_NET_ADMIN, privileged containers, host networking, and broad namespace permissions for untrusted workloads.
• Monitor vendor kernel advisories for exact fixed package versions and deploy the first available fixed or backported kernel release.
• Reboot systems after kernel updates and verify the running kernel version is the patched version.
• Search kernel logs and crash telemetry for use-after-free, KASAN, oops, or panic signatures involving nf_conntrack expectations or exp_seq_show.
• If immediate patching is not possible, restrict local shell access, disable unprivileged user namespaces where compatible, and remove unnecessary conntrack helper modules or features.