CVE-2025-38472

一、漏洞信息
 漏洞编号：[CVE-2025-38472](https://nvd.nist.gov/vuln/detail/CVE-2025-38472)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：N/A None
  Vector：CVSS：3.0/
 漏洞简述：
  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 conntrackentry 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 ina 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 ignorect->status and pretend its 0, the entry matches those that are newlyallocated 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 beforechecking for expiry and/or confirm bit.					->refcnt set to 1					E now owned by skb					->timeout set to 30000If cpu y were to resume now, it would observe E asexpired 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_listsEven 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 unlinkE 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 getsdestroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy.To resolve this, move the IPS_CONFIRMED assignment after the tableinsertion but before the unlock.Pablo points out that the confirm-bit-store could be reordered to happenbefore hlist add resp. the timeout fixup, so switch to set_bit andbefore_atomic memory barrier to prevent this.It doesn t matter if other CPUs can observe a newly inserted entry rightbefore 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 anexpiry check. After this patch, once the confirmed bit check pas---truncated---
 漏洞公开时间：2025-07-28 20:15:29
 漏洞创建时间：2025-07-28 20:33:11
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2025-38472
<details>
<summary>更多参考(点击展开)</summary>

无
</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  七彩瞬析开源风险感知平台
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
| gregkh/linux |  | https://github.com/gregkh/linux/commit/2d72afb340657f03f7261e9243b44457a9228ac7.patch |  | ljqc |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
                            经确认，v6.6分支代码中存在该问题，需要修复。V5.10分支没有对应的代码，不存在该漏洞。             
 openEuler评分：
  3.9
 Vector：CVSS：3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
 受影响版本排查(受影响/不受影响)：
  1.master(6.12.33):受影响
2.openEuler-24.03-LTS:受影响
3.openEuler-24.03-LTS-Next:受影响
4.openEuler-24.03-LTS-SP1:受影响
5.openEuler-24.03-LTS-SP2:受影响
6.openEuler-20.03-LTS-SP4(4.19.90):不受影响
7.openEuler-22.03-LTS-SP3(5.10.0):不受影响
8.openEuler-22.03-LTS-SP4(5.10.0):不受影响

修复是否涉及abi变化(是/否)：
  1.master(6.12.33):否
2.openEuler-20.03-LTS-SP4(4.19.90):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.openEuler-22.03-LTS-SP4(5.10.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否
8.openEuler-24.03-LTS-SP2:否

原因说明：
  1.master(6.12.33):正常修复
2.openEuler-24.03-LTS:正常修复
3.openEuler-24.03-LTS-Next:正常修复
4.openEuler-24.03-LTS-SP1:正常修复
5.openEuler-24.03-LTS-SP2:正常修复
6.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在
7.openEuler-22.03-LTS-SP3(5.10.0):不受影响-漏洞代码不存在
8.openEuler-22.03-LTS-SP4(5.10.0):不受影响-漏洞代码不存在

src-openEuler/kernel
Closed

Content Risk Flag

Comments (5)

src-openEuler/kernelClosed .gitee-modal { width: 500px !important; }

Content Risk Flag

CVE-2025-38472

Comments (5)

Search

src-openEuler/kernel
Closed