{"id":"DEBIAN-CVE-2025-38472","details":"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-\u003estatus is equal to IPS_CONFIRMED|IPS_DYING, which is expected  ct-\u003etimeout is 30000 (=30s), which is unexpected.  Everything else looks like normal udp conntrack entry.  If we ignore ct-\u003estatus 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-\u003etimeout 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 \t\t\tcpu y\t\t\tcpu z  found entry E\t\tfound entry E  E is expired\t\t\u003cpreemption\u003e  nf_ct_delete()  return E to rcu slab \t\t\t\t\tinit_conntrack \t\t\t\t\tE is re-inited, \t\t\t\t\tct-\u003estatus set to 0 \t\t\t\t\treply tuplehash hnnode.pprev \t\t\t\t\tstores 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.  \t\t\t\t\t-\u003erefcnt set to 1 \t\t\t\t\tE now owned by skb \t\t\t\t\t-\u003etimeout 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.  \t\t\t\t\tnf_conntrack_confirm gets called \t\t\t\t\tsets: ct-\u003estatus |= CONFIRMED \t\t\t\t\tThis is wrong: E is not yet added \t\t\t\t\tto hashtable.  cpu y resumes, it observes E as expired but CONFIRMED: \t\t\t\u003cresumes\u003e \t\t\tnf_ct_expired() \t\t\t -\u003e yes (ct-\u003etimeout is 30s) \t\t\tconfirmed bit set.  cpu y will try to delete E from the hashtable: \t\t\tnf_ct_delete() -\u003e set DYING bit \t\t\t__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:  \t\t\twait for spinlock held by z  \t\t\t\t\tCONFIRMED is set but there is no \t\t\t\t\tguarantee ct will be added to hash: \t\t\t\t\t\"chaintoolong\" or \"clash resolution\" \t\t\t\t\tlogic both skip the insert step. \t\t\t\t\treply hnnode.pprev still stores the \t\t\t\t\thash value.  \t\t\t\t\tunlocks spinlock \t\t\t\t\treturn NF_DROP \t\t\t\u003cunblocks, then \t\t\t crashes on hlist_nulls_del_rcu pprev\u003e  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 -\u003e nf_conntrack_destroy -\u003e 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---","modified":"2026-09-01T16:06:14.806689579Z","published":"2025-07-28T12:15:29.003Z","upstream":["CVE-2025-38472"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2025-38472"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.147-1"}]}],"versions":["6.1.106-1","6.1.106-2","6.1.106-3","6.1.112-1","6.1.115-1","6.1.119-1","6.1.123-1","6.1.124-1","6.1.128-1","6.1.129-1","6.1.133-1","6.1.135-1","6.1.137-1","6.1.139-1","6.1.140-1","6.1.27-1","6.1.37-1","6.1.38-1","6.1.38-2","6.1.38-2~bpo11+1","6.1.38-3","6.1.38-4","6.1.38-4~bpo11+1","6.1.52-1","6.1.55-1","6.1.55-1~bpo11+1","6.1.64-1","6.1.66-1","6.1.67-1","6.1.69-1","6.1.69-1~bpo11+1","6.1.76-1","6.1.76-1~bpo11+1","6.1.82-1","6.1.85-1","6.1.90-1","6.1.90-1~bpo11+1","6.1.94-1","6.1.94-1~bpo11+1","6.1.98-1","6.1.99-1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-38472.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.41-1"}]}],"versions":["6.12.38-1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-38472.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.16.3-1"}]}],"versions":["6.12.100-1","6.12.101-1","6.12.105-1","6.12.107-1","6.12.38-1","6.12.41-1","6.12.43-1","6.12.43-1~bpo12+1","6.12.48-1","6.12.57-1","6.12.57-1~bpo12+1","6.12.63-1","6.12.63-1~bpo12+1","6.12.69-1","6.12.69-1~bpo12+1","6.12.73-1","6.12.73-1~bpo12+1","6.12.74-1","6.12.74-2","6.12.74-2~bpo12+1","6.12.85-1","6.12.85-1~bpo12+1","6.12.86-1","6.12.86-1~bpo12+1","6.12.88-1","6.12.88-1~bpo12+1","6.12.90-1","6.12.90-1~bpo12+1","6.12.90-2","6.12.90-2~bpo12+1","6.12.94-1","6.12.94-1~bpo12+1","6.12.95-1","6.12.95-1~bpo12+1","6.12.96-1","6.13.10-1~exp1","6.13.11-1~exp1","6.13.2-1~exp1","6.13.3-1~exp1","6.13.4-1~exp1","6.13.5-1~exp1","6.13.6-1~exp1","6.13.7-1~exp1","6.13.8-1~exp1","6.13.9-1~exp1","6.13~rc6-1~exp1","6.13~rc7-1~exp1","6.14.3-1~exp1","6.14.5-1~exp1","6.14.6-1~exp1","6.15-1~exp1","6.15.1-1~exp1","6.15.2-1~exp1","6.15.3-1~exp1","6.15.4-1~exp1","6.15.5-1~exp1","6.15.6-1~exp1","6.15~rc7-1~exp1","6.16-1~exp1","6.16.1-1~exp1","6.16.3-1~bpo13+1","6.16~rc7-1~exp1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-38472.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}