CVE-2023-53382

Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
18/09/2025
Last modified:
19/09/2025

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Reset connection when trying to use SMCRv2 fails.<br /> <br /> We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It<br /> can be reproduced by:<br /> <br /> - smc_run nginx<br /> - smc_run wrk -t 32 -c 500 -d 30 http://:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000014<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42<br /> Workqueue: smc_hs_wq smc_listen_work [smc]<br /> RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc]<br /> RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06<br /> RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000<br /> RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00<br /> RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000<br /> R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180<br /> R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001<br /> FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]<br /> ? smcr_buf_map_link+0x24b/0x290 [smc]<br /> ? __smc_buf_create+0x4ee/0x9b0 [smc]<br /> smc_clc_send_accept+0x4c/0xb0 [smc]<br /> smc_listen_work+0x346/0x650 [smc]<br /> ? __schedule+0x279/0x820<br /> process_one_work+0x1e5/0x3f0<br /> worker_thread+0x4d/0x2f0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe5/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> <br /> During the CLC handshake, server sequentially tries available SMCRv2<br /> and SMCRv1 devices in smc_listen_work().<br /> <br /> If an SMCRv2 device is found. SMCv2 based link group and link will be<br /> assigned to the connection. Then assumed that some buffer assignment<br /> errors happen later in the CLC handshake, such as RMB registration<br /> failure, server will give up SMCRv2 and try SMCRv1 device instead. But<br /> the resources assigned to the connection won&amp;#39;t be reset.<br /> <br /> When server tries SMCRv1 device, the connection creation process will<br /> be executed again. Since conn-&gt;lnk has been assigned when trying SMCRv2,<br /> it will not be set to the correct SMCRv1 link in<br /> smcr_lgr_conn_assign_link(). So in such situation, conn-&gt;lgr points to<br /> correct SMCRv1 link group but conn-&gt;lnk points to the SMCRv2 link<br /> mistakenly.<br /> <br /> Then in smc_clc_send_confirm_accept(), conn-&gt;rmb_desc-&gt;mr[link-&gt;link_idx]<br /> will be accessed. Since the link-&gt;link_idx is not correct, the related<br /> MR may not have been initialized, so crash happens.<br /> <br /> | Try SMCRv2 device first<br /> | |-&gt; conn-&gt;lgr: assign existed SMCRv2 link group;<br /> | |-&gt; conn-&gt;link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC);<br /> | |-&gt; sndbuf &amp; RMB creation fails, quit;<br /> |<br /> | Try SMCRv1 device then<br /> | |-&gt; conn-&gt;lgr: create SMCRv1 link group and assign;<br /> | |-&gt; conn-&gt;link: keep SMCRv2 link mistakenly;<br /> | |-&gt; sndbuf &amp; RMB creation succeed, only RMB-&gt;mr[link_idx = 0]<br /> | initialized.<br /> |<br /> | Then smc_clc_send_confirm_accept() accesses<br /> | conn-&gt;rmb_desc-&gt;mr[conn-&gt;link-&gt;link_idx, which is 1], then crash.<br /> v<br /> <br /> This patch tries to fix this by cleaning conn-&gt;lnk before assigning<br /> link. In addition, it is better to reset the connection and clean the<br /> resources assigned if trying SMCRv2 failed in buffer creation or<br /> registration.

Impact