GHSA-979q-6jjc-29jh 
In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack: fix crash due to removal of uninitialised entryA 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 hashct->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.If cpu y were to resume now, it would observe E as
expired but would skip E due to missing CONFIRMED bit.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_listsEven this scenario doesn't guarantee a crash:
cpu z still holds the table bucket lock(s) so y blocks: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:Check if entry has expired, if not skip to next entryObtain a reference to the expired entry.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---
CVSS v3.1 score: 5.5