CVE-2026-53349

What it actually does

This is a Linux kernel use-after-free condition in netfilter connection tracking expectations used by NAT helpers such as the H.323 helper. A helper can leave a pending expectation containing a function pointer into module code that has been unloaded. When traffic later matches that expectation, the kernel may call the stale function pointer from init_conntrack(), dereferencing freed module text. In the demonstrated case this causes a kernel Oops/crash; because the stale pointer is a kernel callback, the class of bug is memory-corruption sensitive, but reaching the vulnerable state requires CAP_SYS_MODULE in the initial user namespace, so practical exploitation is primarily a local privileged denial-of-service/robustness issue rather than a typical remote compromise path.

Why it matters to the business

Systems using affected Linux kernels with netfilter connection tracking/NAT helper modules could be crashed by a user or process that already has high local privileges to unload kernel modules. The main operational risk is unexpected host outage, disruption of network workloads, firewall/NAT services, containers, or appliances built on Linux networking. EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so urgency is lower than internet-exposed remote flaws, but kernel fixes should still be applied during normal patch cycles, especially on systems where privileged users, automation, or appliances can load and unload netfilter helper modules.

How an attack unfolds

An attacker first needs local administrative-level capability equivalent to CAP_SYS_MODULE in the initial user namespace. They load or rely on a vulnerable netfilter NAT helper such as nf_nat_h323/nf_conntrack_h323, then create protocol traffic that causes the helper to register a connection-tracking expectation with an expectfn callback pointing into the helper module. Before that expected connection arrives, the attacker unloads the NAT helper module. In vulnerable kernels, unregistering the helper removes the descriptor but does not destroy existing expectations that reference the helper callback. When the attacker then sends traffic matching the expected connection, nf_conntrack processes the expectation and init_conntrack() invokes the stale exp->expectfn pointer. Because the target code belonged to an unloaded module, the kernel accesses freed text and can Oops or panic, causing denial of service. The upstream fix destroys matching expectations during helper unregister so no expectation can outlive the module code it references.

How to fix it

Upgrade to a Linux kernel release from the relevant distribution or vendor that includes the netfilter fix adding destruction of stale expectation callbacks during NAT helper unregister, specifically the logic equivalent to nf_ct_helper_expectfn_destroy(). Because no product-specific fixed versions were provided, use vendor kernel advisories and changelogs to identify the first fixed package for each distribution. Where immediate patching is not possible, reduce exposure by preventing untrusted administrators or workloads from obtaining CAP_SYS_MODULE, disabling unnecessary kernel module loading, avoiding dynamic unload/reload of netfilter NAT helper modules, and not loading unused helpers such as H.323 helpers. Consider module lockdown, secure boot lockdown modes, allowlisting of loadable modules, and operational controls around modprobe/rmmod on production systems.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not only that an updated package is installed. Validate with uname -r, package manager metadata, and vendor security advisory references for this CVE or the netfilter nf_conntrack expectation fix. If source or build artifacts are available, confirm the kernel contains logic equivalent to nf_ct_helper_expectfn_destroy() and that NAT helper exit paths destroy expectations after unregister/RCU handling. Operationally, check that unnecessary NAT helper modules are not loaded with lsmod, and verify controls prevent unauthorized module unloads. For high-assurance validation in a lab only, reproduce the helper load/expectation/unload/expected-connection sequence on a non-production system and confirm the fixed kernel does not Oops or panic.

Typical attack path

1. Obtain local privileged execution with CAP_SYS_MODULE in the initial user namespace.
2. Load or use a vulnerable netfilter NAT helper module, such as H.323-related helpers.
3. Generate protocol traffic that creates a pending connection-tracking expectation using the helper callback.
4. Unload the NAT helper module while the expectation is still live.
5. Send traffic that matches the pending expected connection.
6. Trigger nf_conntrack to call the stale expectation callback, resulting in a kernel Oops/panic or other memory-corruption behavior.

How to detect it

To determine whether this was already triggered, review kernel logs from journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, and crash dump systems for Oops, panic, BUG, KASAN, or stack traces involving nf_conntrack, init_conntrack(), and H.323 netfilter modules. Correlate any crash with module unload activity from auditd, systemd journal, shell history, EDR telemetry, or process accounting, especially delete_module, rmmod, or modprobe -r events for nf_nat_h323 or related NAT helpers. Look for the sequence of a helper module being unloaded followed shortly by connection-tracking activity and a kernel Oops. If kdump/vmcore is available, inspect the crashing instruction pointer and stack for calls through exp->expectfn from init_conntrack() into an address associated with an unloaded module. Absence of these artifacts does not prove non-exploitation if logs rotated or the host crashed without persistent logging.

• Oops: int3
• kernel BUG
• KASAN
• init_conntrack.isra.0
• init_conntrack
• nf_conntrack_in
• nf_conntrack_core.c
• ipv4_conntrack_local
• nf_hook_slow
• nf_nat_h323
• nf_conntrack_h323
• Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]
• last unloaded: nf_nat_h323
• ip_nat_q931_expect
• delete_module
• rmmod nf_nat_h323
• modprobe -r nf_nat_h323

What your security team should do

• Inventory Linux systems that use netfilter connection tracking, NAT helpers, firewall/NAT functions, VoIP/H.323 helpers, or network appliance roles.
• Patch affected kernels through normal vendor kernel update channels; prioritize systems where privileged local users, automation, or third-party management agents can load/unload kernel modules.
• Restrict CAP_SYS_MODULE and kernel module management to highly trusted administrative paths only.
• Disable or avoid loading unused netfilter NAT helper modules, especially legacy protocol helpers such as H.323 if not required.
• Monitor kernel logs for Oops/panic traces involving nf_conntrack, init_conntrack, and recently unloaded NAT helper modules.
• Review audit logs for suspicious or unexpected delete_module/rmmod/modprobe activity involving nf_nat_h323, nf_conntrack_h323, or other netfilter helper modules.
• Because this is not KEV-listed, not known ransomware-used, and has very low EPSS, treat it as a kernel hardening and availability patch rather than an emergency internet-exploitation event unless local privilege abuse is suspected.