CVE-2026-53349

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_conntrack: destroy stale expectfn expectations on unregister

NAT helpers such as nf_nat_h323 store a raw pointer to module text in

exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()

only unlinks the callback descriptor and never walks the expectation table,

so an expectation pending at module removal survives with a dangling

exp->expectfn into freed module text.

When the expected connection arrives, init_conntrack() invokes

exp->expectfn(), now a stale pointer into the unloaded module. Reproduced

on a KASAN build by loading the H.323 helpers, creating a Q.931

expectation, unloading nf_nat_h323, then connecting to the expected port:

Oops: int3: 0000 [#1] SMP KASAN NOPTI

RIP: 0010:0xffffffffa06102d1

init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862)

nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049)

ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223)

nf_hook_slow (net/netfilter/core.c:619)

__ip_local_out (net/ipv4/ip_output.c:120)

__tcp_transmit_skb (net/ipv4/tcp_output.c:1715)

tcp_connect (net/ipv4/tcp_output.c:4374)

tcp_v4_connect (net/ipv4/tcp_ipv4.c:345)

__sys_connect (net/socket.c:2167)

Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]

Reaching the dangling state requires CAP_SYS_MODULE in the initial user

namespace to remove a NAT helper that still has live expectations, so this

is a robustness fix; leaving an expectation pointing at freed text is wrong

regardless.

Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and

drops every expectation whose ->expectfn matches the descriptor being torn

down. Call it from each NAT helper's exit path after the existing RCU grace

period, so no expectation outlives the code it points at and no extra

synchronize_rcu() is introduced. With the fix, the same reproducer runs to

completion without the Oops.