CVE-2023-53382

一、漏洞信息
 漏洞编号：[CVE-2023-53382](https://nvd.nist.gov/vuln/detail/CVE-2023-53382)
 漏洞归属组件：[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.x分值：
  BaseScore：N/A None
  Vector：
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:net/smc: Reset connection when trying to use SMCRv2 fails.We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. Itcan be reproduced by:- smc_run nginx- smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G        W   E      6.4.0-rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS:  0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>  ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]  ? smcr_buf_map_link+0x24b/0x290 [smc]  ? __smc_buf_create+0x4ee/0x9b0 [smc]  smc_clc_send_accept+0x4c/0xb0 [smc]  smc_listen_work+0x346/0x650 [smc]  ? __schedule+0x279/0x820  process_one_work+0x1e5/0x3f0  worker_thread+0x4d/0x2f0  ? __pfx_worker_thread+0x10/0x10  kthread+0xe5/0x120  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2c/0x50  </TASK>During the CLC handshake, server sequentially tries available SMCRv2and SMCRv1 devices in smc_listen_work().If an SMCRv2 device is found. SMCv2 based link group and link will beassigned to the connection. Then assumed that some buffer assignmenterrors happen later in the CLC handshake, such as RMB registrationfailure, server will give up SMCRv2 and try SMCRv1 device instead. Butthe resources assigned to the connection won t be reset.When server tries SMCRv1 device, the connection creation process willbe executed again. Since conn->lnk has been assigned when trying SMCRv2,it will not be set to the correct SMCRv1 link insmcr_lgr_conn_assign_link(). So in such situation, conn->lgr points tocorrect SMCRv1 link group but conn->lnk points to the SMCRv2 linkmistakenly.Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx]will be accessed. Since the link->link_idx is not correct, the relatedMR may not have been initialized, so crash happens. | Try SMCRv2 device first |     |-> conn->lgr:	assign existed SMCRv2 link group; |     |-> conn->link:	assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); |     |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then |     |-> conn->lgr:	create SMCRv1 link group and assign; |     |-> conn->link:	keep SMCRv2 link mistakenly; |     |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] |         initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. vThis patch tries to fix this by cleaning conn->lnk before assigninglink. In addition, it is better to reset the connection and clean theresources assigned if trying SMCRv2 failed in buffer creation orregistration.
 漏洞公开时间：2025-09-18 22:15:41
 漏洞创建时间：2025-09-18 22:41:27
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2023-53382
<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://git.kernel.org/stable/c/9540765d1882d15497d880096de99fafabcfa08c |  | ljqc |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:net/smc: Reset connection when trying to use SMCRv2 fails.We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. Itcan be reproduced by:- smc_run nginx- smc_run wrk -t 32 -c 500 -d 30 http://&lt;ip&gt;:&lt;port&gt; BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G        W   E      6.4.0-rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS:  0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  &lt;TASK&gt;  ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]  ? smcr_buf_map_link+0x24b/0x290 [smc]  ? __smc_buf_create+0x4ee/0x9b0 [smc]  smc_clc_send_accept+0x4c/0xb0 [smc]  smc_listen_work+0x346/0x650 [smc]  ? __schedule+0x279/0x820  process_one_work+0x1e5/0x3f0  worker_thread+0x4d/0x2f0  ? __pfx_worker_thread+0x10/0x10  kthread+0xe5/0x120  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2c/0x50  &lt;/TASK&gt;During the CLC handshake, server sequentially tries available SMCRv2and SMCRv1 devices in smc_listen_work().If an SMCRv2 device is found. SMCv2 based link group and link will beassigned to the connection. Then assumed that some buffer assignmenterrors happen later in the CLC handshake, such as RMB registrationfailure, server will give up SMCRv2 and try SMCRv1 device instead. Butthe resources assigned to the connection won t be reset.When server tries SMCRv1 device, the connection creation process willbe executed again. Since conn-&gt;lnk has been assigned when trying SMCRv2,it will not be set to the correct SMCRv1 link insmcr_lgr_conn_assign_link(). So in such situation, conn-&gt;lgr points tocorrect SMCRv1 link group but conn-&gt;lnk points to the SMCRv2 linkmistakenly.Then in smc_clc_send_confirm_accept(), conn-&gt;rmb_desc-&gt;mr[link-&gt;link_idx]will be accessed. Since the link-&gt;link_idx is not correct, the relatedMR may not have been initialized, so crash happens. | Try SMCRv2 device first |     |-&gt; conn-&gt;lgr:assign existed SMCRv2 link group; |     |-&gt; conn-&gt;link:assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); |     |-&gt; sndbuf &amp; RMB creation fails, quit; | | Try SMCRv1 device then |     |-&gt; conn-&gt;lgr:create SMCRv1 link group and assign; |     |-&gt; conn-&gt;link:keep SMCRv2 link mistakenly; |     |-&gt; sndbuf &amp; RMB creation succeed, only RMB-&gt;mr[link_idx = 0] |         initialized. | | Then smc_clc_send_confirm_accept() accesses | conn-&gt;rmb_desc-&gt;mr[conn-&gt;link-&gt;link_idx, which is 1], then crash. vThis patch tries to fix this by cleaning conn-&gt;lnk before assigninglink. In addition, it is better to reset the connection and clean theresources assigned if trying SMCRv2 failed in buffer creation orregistration.The Linux kernel CVE team has assigned CVE-2023-53382 to this issue.
 openEuler评分：
  5.3
 Vector：CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H
 受影响版本排查(受影响/不受影响)：
  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.6.0):不受影响
6.openEuler-24.03-LTS-Next(6.6.0):不受影响
7.openEuler-24.03-LTS-SP1(6.6.0):不受影响
8.openEuler-24.03-LTS-SP2(6.6.0):不受影响
9.openEuler-24.03-LTS-SP3(6.6.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.6.0):否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-24.03-LTS-SP1(6.6.0):否
8.openEuler-24.03-LTS-SP2(6.6.0):否
9.openEuler-24.03-LTS-SP3(6.6.0):否

原因说明：
  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.6.0):不受影响-漏洞代码不能被攻击者触发
6.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1(6.6.0):不受影响-漏洞代码不能被攻击者触发
8.openEuler-24.03-LTS-SP2(6.6.0):不受影响-漏洞代码不能被攻击者触发
9.openEuler-24.03-LTS-SP3(6.6.0):不受影响-漏洞代码不能被攻击者触发

src-openEuler/kernel
关闭

内容风险标识

评论 (5)

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

内容风险标识

CVE-2023-53382

评论 (5)

搜索帮助

src-openEuler/kernel
关闭