CVE-2023-53382
Publication date:
18/09/2025
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&#39;t be reset.<br />
<br />
When server tries SMCRv1 device, the connection creation process will<br />
be executed again. Since conn->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->lgr points to<br />
correct SMCRv1 link group but conn->lnk points to the SMCRv2 link<br />
mistakenly.<br />
<br />
Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx]<br />
will be accessed. Since the link->link_idx is not correct, the related<br />
MR may not have been initialized, so crash happens.<br />
<br />
| Try SMCRv2 device first<br />
| |-> conn->lgr: assign existed SMCRv2 link group;<br />
| |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC);<br />
| |-> sndbuf & RMB creation fails, quit;<br />
|<br />
| Try SMCRv1 device then<br />
| |-> conn->lgr: create SMCRv1 link group and assign;<br />
| |-> conn->link: keep SMCRv2 link mistakenly;<br />
| |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0]<br />
| initialized.<br />
|<br />
| Then smc_clc_send_confirm_accept() accesses<br />
| conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash.<br />
v<br />
<br />
This patch tries to fix this by cleaning conn->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.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025