CVE-2025-38472 Information

Jul 29, 2025 cve

Description

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 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: 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:
				## Reference

https://git.kernel.org/stable/c/2d72afb340657f03f7261e9243b44457a9228ac7 https://git.kernel.org/stable/c/76179961c423cd698080b5e4d5583cf7f4fcdde9 https://git.kernel.org/stable/c/938ce0e8422d3793fe30df2ed0e37f6bc0598379 https://git.kernel.org/stable/c/a47ef874189d47f934d0809ae738886307c0ea22 https://git.kernel.org/stable/c/fc38c249c622ff5e3011b8845fd49dbfd9289afc

CNNVD-202507-3471 (Published: 2025-07-28)

Share on: