CVE-2026-53349

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack: destroy stale expectfn expectations on unregister<br /> <br /> NAT helpers such as nf_nat_h323 store a raw pointer to module text in<br /> exp-&gt;expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()<br /> only unlinks the callback descriptor and never walks the expectation table,<br /> so an expectation pending at module removal survives with a dangling<br /> exp-&gt;expectfn into freed module text.<br /> <br /> When the expected connection arrives, init_conntrack() invokes<br /> exp-&gt;expectfn(), now a stale pointer into the unloaded module. Reproduced<br /> on a KASAN build by loading the H.323 helpers, creating a Q.931<br /> expectation, unloading nf_nat_h323, then connecting to the expected port:<br /> <br /> Oops: int3: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:0xffffffffa06102d1<br /> init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862)<br /> nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049)<br /> ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223)<br /> nf_hook_slow (net/netfilter/core.c:619)<br /> __ip_local_out (net/ipv4/ip_output.c:120)<br /> __tcp_transmit_skb (net/ipv4/tcp_output.c:1715)<br /> tcp_connect (net/ipv4/tcp_output.c:4374)<br /> tcp_v4_connect (net/ipv4/tcp_ipv4.c:345)<br /> __sys_connect (net/socket.c:2167)<br /> Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]<br /> <br /> Reaching the dangling state requires CAP_SYS_MODULE in the initial user<br /> namespace to remove a NAT helper that still has live expectations, so this<br /> is a robustness fix; leaving an expectation pointing at freed text is wrong<br /> regardless.<br /> <br /> Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and<br /> drops every expectation whose -&gt;expectfn matches the descriptor being torn<br /> down. Call it from each NAT helper&amp;#39;s exit path after the existing RCU grace<br /> period, so no expectation outlives the code it points at and no extra<br /> synchronize_rcu() is introduced. With the fix, the same reproducer runs to<br /> completion without the Oops.