CVE-2026-53349: Linux Kernel Netfilter Dangling Pointer Denial of Service

Technical summary

The Linux kernel's netfilter NAT helpers store raw function pointers in expectation table entries (exp->expectfn) that reference helper code. The nf_ct_helper_expectfn_unregister() function, invoked during module unload, only unlinks the callback descriptor without removing stale expectations that reference the helper being unloaded. If a matching network connection arrives after module removal, init_conntrack() dereferences the dangling pointer and jumps into freed module text. The fix introduces nf_ct_helper_expectfn_destroy(), which walks the expectation table at helper unload time, finds and destroys all expectations whose expectfn pointers match the descriptor being torn down, eliminating the dangling reference before the module code is freed.

Business impact

This vulnerability primarily affects systems running NAT helper modules (H.323, SIP, PPTP, etc.) that handle specialized protocol tracking. The practical impact is a kernel denial of service: when the specific sequence of conditions is met (module unload with pending expectations, followed by connection arrival), the kernel crashes and requires a reboot. Systems relying on continuous network availability—particularly those with dynamic protocol helper management—face service interruption. The requirement for CAP_SYS_MODULE privilege narrows the threat to local actors or those who can escalate privileges, but automated deployment environments that dynamically load/unload helpers warrant immediate attention.

Affected systems

All Linux kernel versions incorporating the vulnerable netfilter architecture are affected, specifically those using NAT helper modules including nf_nat_h323, nf_nat_sip, nf_nat_pptp, and similar helpers. The vulnerability manifests most readily in distributions that modularize these helpers separately from the core kernel. Systems with stable, static helper module loading (helpers never unloaded) have reduced practical risk, though the underlying defect remains. Embedded Linux systems, container orchestration platforms with kernel module hot-loading, and NAT gateway appliances are most exposed.

Exploitability

Exploitability is constrained by privilege requirements. An attacker must possess CAP_SYS_MODULE capability within the initial user namespace—effectively requiring root or a process with explicit SYS_MODULE capability—to unload the helper module. Crafting the crash further requires inducing a network connection matching the unloaded helper's protocol within a narrow window after unload. The vulnerability does not enable privilege escalation, code execution, or information disclosure; the only outcome is denial of service via kernel panic. This limits the threat model to local actors or those already possessing significant system compromise.

Remediation

Apply the upstream Linux kernel patch that adds the nf_ct_helper_expectfn_destroy() function and integrates it into the helper unregister path. The fix is incorporated into mainstream kernel trees following the published patch. Verify the patch release version from your distribution's advisory; most major distributions will backport this fix into their stable/long-term support branches. For systems unable to patch immediately, segregate or restrict root-equivalent access and audit for unnecessary or rarely-used NAT helper modules that can be permanently disabled at compile time.

Patch guidance

Obtain patches from your Linux distribution's security update channel. Upstream kernel patches for this vulnerability should be available in mainline releases shortly after publication. Verify the specific kernel version recommended for your distribution against the official security advisory; version numbering varies across distributions. Most users will receive updates through standard package managers (apt, yum, dnf, etc.). For embedded or custom kernels, reference the upstream netfilter subsystem patches in the kernel git repository. Testing in a non-production environment is recommended before deploying to production systems, particularly for builds relying on dynamic NAT helper modules.

Detection guidance

Look for kernel log entries indicating unhandled faults in init_conntrack() or references to freed module text, particularly in KASAN or SLUB builds where memory access violations are instrumented. Monitoring for unexpected kernel panics or system reboots following NAT helper module unload operations may indicate exploitation attempts or accidental trigger scenarios. Security Information and Event Management (SIEM) systems should flag CAP_SYS_MODULE use followed by module unload operations, especially in restricted environments. Systems with CONFIG_KASAN enabled will immediately surface the use-after-free; production systems without KASAN instrumentation may only register a kernel panic with minimal diagnostic output.

Why prioritize this

Although the CVSS score of 5.5 reflects local-only, privilege-restricted impact, this vulnerability warrants prompt patching because (1) it affects kernel stability and availability directly, (2) it represents a clear memory safety defect in a critical subsystem (netfilter), and (3) many NAT-heavy deployments (firewalls, gateways, container environments) rely on these helpers. The fix is non-invasive and introduces no performance overhead, making deployment low-risk. Prioritize systems running unstable or frequently-modified helper module configurations above systems with statically-loaded helpers.

Risk score, explained

The CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H score accurately reflects the attack surface: local attack vector, low complexity, low-privilege requirement, no user interaction, single system impact, and denial-of-service outcome (availability impact). The score does not assign points for code execution or privilege escalation, both absent from this defect. Organizations should weight this score against their own threat model; environments with strong local privilege boundaries and minimal untrusted local access can accept slightly higher risk, whereas shared hosting or container platforms should treat this as moderate-to-high priority.

Frequently asked questions