CVE-2026-43450

What it actually does

This Linux kernel flaw is an out-of-bounds read in the netfilter connection-tracking helper netlink dump path, specifically nfnl_cthelper_dump_table(). A race/logic error can occur when a saved helper entry is deleted between netlink dump rounds: the dump code can restart iteration after the helper hash-table index has already reached the table size, bypassing the bounds check and reading 8 bytes beyond nf_ct_helper_hash. The practical technical impact is potential kernel memory disclosure and kernel crash/panic, depending on kernel configuration, allocator layout, and whether hardening such as KASAN, panic-on-oops, or slab protections are enabled. The vulnerability is local, requires some level of local privilege, requires no user interaction, and does not directly provide integrity modification by itself.

Why it matters to the business

An attacker with local access to an affected Linux system may be able to crash the host or expose sensitive kernel memory, which can disrupt workloads, cause service outages, and potentially aid follow-on privilege escalation or bypass of kernel address-space protections. The EPSS score is currently very low and the issue is not listed in CISA KEV, so broad real-world exploitation is not indicated, but kernel vulnerabilities still warrant timely remediation because affected systems often underpin critical infrastructure, containers, networking appliances, and multi-user platforms.

How an attack unfolds

An attacker first obtains local execution on an affected Linux host with the privileges needed to interact with the relevant netfilter/nfnetlink connection-tracking helper interfaces. They then exercise the cthelper table dump operation over netlink while causing or racing deletion of the helper entry tracked as the last dumped object between dump rounds. Because the vulnerable code restarts iteration from a label inside the loop body after the hash-table index has reached nf_ct_helper_hsize, the next access reads past the end of the nf_ct_helper_hash array. On some systems this may return adjacent kernel memory to the dump path, creating an information disclosure primitive; on others it may trigger a kernel oops, KASAN report, or panic, resulting in denial of service. There is no current indication from the supplied data that public exploitation, ransomware use, or named threat actor activity is occurring.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the upstream fix for nfnetlink_cthelper nfnl_cthelper_dump_table() bounds handling. Because exact fixed package versions were not provided, use the security advisory and package repository for the relevant distribution or appliance vendor to identify the corrected kernel build, then reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or avoiding unnecessary netfilter connection-tracking helper functionality where operationally feasible, enforcing least privilege for CAP_NET_ADMIN and network namespace creation, and using container/runtime policies that prevent untrusted containers from obtaining network administration capabilities. Mitigations should be treated as temporary; the durable remediation is a fixed kernel.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not only the installed package, is at or above the vendor-fixed build and that the host has been rebooted into that kernel. Review the distribution or vendor changelog for a fix referencing nfnetlink_cthelper, nfnl_cthelper_dump_table(), netfilter cthelper dump, or an out-of-bounds read in nf_ct_helper_hash. On systems where source or debug symbols are available, confirm the restart logic is inside the bounds-checked loop as described by the upstream fix. Validate exposure reduction by checking that untrusted users and workloads do not have CAP_NET_ADMIN, cannot create privileged network namespaces unless required, and cannot manipulate netfilter connection-tracking helper state. After patching, monitor kernel logs for absence of new KASAN, slab-out-of-bounds, kernel oops, or panic entries referencing nfnl_cthelper_dump_table.

Typical attack path

1. Gain local code execution on an affected Linux system, for example through a shell, compromised account, container escape prerequisite, or malicious local workload.
2. Obtain or already possess the local privileges required to use the relevant nfnetlink/netfilter connection-tracking helper interface.
3. Create or manipulate netfilter connection-tracking helper state so that helper table dumps can be performed.
4. Start a netlink dump of the connection-tracking helper table.
5. Delete or race the saved helper entry between dump rounds so the vulnerable restart logic is reached after the hash-table index is out of bounds.
6. Trigger the out-of-bounds 8-byte read from nf_ct_helper_hash beyond its valid array boundary.
7. Use the result to attempt kernel memory disclosure or cause a kernel oops/panic leading to denial of service.

How to detect it

To assess whether this was already exploited, review kernel logs and centralized log sources such as journald, /var/log/kern.log, /var/log/messages, dmesg captures, crash dumps, and EDR telemetry for kernel oops, panic, KASAN, or slab out-of-bounds reports involving nfnl_cthelper_dump_table, nfnetlink_cthelper, netlink_dump, or nf_ct_helper_hash. Correlate any such events with local user activity, sudo/auditd records, container runtime events, namespace creation, privileged container launches, CAP_NET_ADMIN grants, and netfilter/nftables/iptables manipulation around the same time. Look for repeated local processes opening NETLINK_NETFILTER sockets followed by recvfrom/netlink dump activity and abnormal termination or host instability. If crash dumps are available, examine call traces for nfnl_cthelper_dump_table -> netlink_dump -> netlink_recvmsg -> sock_recvmsg -> __sys_recvfrom. Because the vulnerability is a local kernel memory-corruption issue, network perimeter logs are unlikely to show direct exploitation unless the attacker first obtained remote code execution by another path.

• KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table
• BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table
• nfnl_cthelper_dump_table+0x
• Read of size 8 at addr
• nf_ct_helper_hash
• nfnetlink_cthelper
• netfilter: nfnetlink_cthelper
• netlink_dump+0x
• netlink_recvmsg+0x
• sock_recvmsg+0x
• __sys_recvfrom+0x
• __x64_sys_recvfrom+0x
• poc_cthelper
• kernel BUG at
• Kernel panic
• Oops:
• general protection fault
• KASAN: slab-out-of-bounds

What your security team should do

• Prioritize patching internet-facing infrastructure hosts, multi-tenant systems, container hosts, CI runners, bastion hosts, and systems where untrusted users or workloads can obtain local execution.
• Identify all Linux assets using vendor kernel inventories and confirm which are running affected kernel lines; remember that installed-but-not-running kernel updates do not remediate until reboot.
• Restrict CAP_NET_ADMIN and privileged container usage to trusted workloads only; review Kubernetes, container runtime, and sudo policies that may grant network administration capabilities.
• Search kernel logs and centralized logging for KASAN, slab-out-of-bounds, oops, or panic events referencing nfnl_cthelper_dump_table, nfnetlink_cthelper, or nf_ct_helper_hash.
• If suspicious crashes are observed, preserve kernel logs, audit logs, container metadata, shell history where available, and workload provenance for incident response.
• Track vendor advisories for exact fixed kernel package versions because none were supplied in the input data.
• Treat exploitation risk as currently lower due to low EPSS, no KEV listing, and no reported exploit maturity, but do not defer indefinitely because successful exploitation can affect host stability and kernel memory confidentiality.