CVE-2025-38472: In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_conntrack: fix crash due to removal of uninitialised entry  A crash in conntrack was reported while trying to unlink the conntrack entry from the hash bucket list:     [exception RIP: __nf_ct_delete_from_lists+172]     [..]  #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]  #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack]  #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack]     [..]  The nf_conn struct is marked as allocated from slab but appears to be in a partially initialised state:   ct hlist pointer is garbage; looks like the ct hash value  (hence crash).  ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected  ct->timeout is 30000 (=30s), which is unexpected.  Everything else looks like normal udp conntrack entry.  If we ignore ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into the hash:   - ct hlist pointers are overloaded and store/cache the raw tuple hash   - ct->timeout matches the relative time expected for a new udp flow     rather than the absolute 'jiffies' value.  If it were not for the presence of IPS_CONFIRMED, __nf_conntrack_find_get() would have skipped the entry.  Theory is that we did hit following race:  cpu x    cpu y   cpu z  found entry E  found entry E  E is expired  <preemption>  nf_ct_delete()  return E to rcu slab      init_conntrack      E is re-inited,      ct->status set to 0      reply tuplehash hnnode.pprev      stores hash value.  cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z.  cpu y was preempted before checking for expiry and/or confirm bit.       ->refcnt set to 1      E now owned by skb      ->timeout set to 30000  If cpu y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit.       nf_conntrack_confirm gets called      sets: ct->status |= CONFIRMED      This is wrong: E is not yet added      to hashtable.  cpu y resumes, it observes E as expired but CONFIRMED:    <resumes>    nf_ct_expired()     -> yes (ct->timeout is 30s)    confirmed bit set.  cpu y will try to delete E from the hashtable:    nf_ct_delete() -> set DYING bit    __nf_ct_delete_from_lists  Even this scenario doesn't guarantee a crash: cpu z still holds the table bucket lock(s) so y blocks:     wait for spinlock held by z       CONFIRMED is set but there is no      guarantee ct will be added to hash:      "chaintoolong" or "clash resolution"      logic both skip the insert step.      reply hnnode.pprev still stores the      hash value.       unlocks spinlock      return NF_DROP    <unblocks, then     crashes on hlist_nulls_del_rcu pprev>  In case CPU z does insert the entry into the hashtable, cpu y will unlink E again right away but no crash occurs.  Without 'cpu y' race, 'garbage' hlist is of no consequence: ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy.  To resolve this, move the IPS_CONFIRMED assignment after the table insertion but before the unlock.  Pablo points out that the confirm-bit-store could be reordered to happen before hlist add resp. the timeout fixup, so switch to set_bit and before_atomic memory barrier to prevent this.  It doesn't matter if other CPUs can observe a newly inserted entry right before the CONFIRMED bit was set:  Such event cannot be distinguished from above "E is the old incarnation" case: the entry will be skipped.  Also change nf_ct_should_gc() to first check the confirmed bit.  The gc sequence is:  1. Check if entry has expired, if not skip to next entry  2. Obtain a reference to the expired entry.  3. Call nf_ct_should_gc() to double-check step 1.  nf_ct_should_gc() is thus called only for entries that already failed an expiry check. After this patch, once the confirmed bit check pas ---truncated---