Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - net/smc尝试使用 SMCRv2 失败时重置连接。我们发现将 SMCRv2 与 2 Mellanox ConnectX-4 配合使用时会发生崩溃。它<port> 可以<ip>通过以下方式重现PFerror_code(0x0000) - not-present 页面 PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump已加载 Tainted: GWE 6.4.0 -rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP:
    0010smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP0018:ffffb8294b2d7c78 EFLAGS00010a06 RAX
    ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10:
     R110000000000000400  : 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:000000 DR3:000000000000000000000
    00000000fffe0ff0 DR7: 0000000000000400 调用跟踪 <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> 在 CLC 握手期间服务器会按顺序尝试 smc_listen_work() 中可用的 SMCRv2 和 SMCRv1 设备。是否找到 SMCRv2 设备。基于 SMCv2 的链接组和链接将分配给该连接。然后假设稍后在 CLC 握手中发生某些缓冲区分配错误例如 MBR 注册失败服务器将放弃 SMCRv2 并尝试使用 SMCRv1 设备。但不会重置分配给该连接的资源。服务器尝试 SMCRv1 设备时将再次执行连接创建过程。由于在尝试 SMCRv2 时已分配 conn->lnk因此不会在 smcr_lgr_conn_assign_link() 中将其设置为正确的 SMCRv1 链接。因此在这种情况下conn->lgr 会正确指向 SMCRv1 链接组但 conn->lnk 会错误地指向 SMCRv2 链接。然后在 smc_clc_send_confirm_accept() 中将会访问 conn->rmb_desc->mr[link->link_idx]。由于 link->link_idx 不正确相关 MR 可能未初始化因此会发生崩溃。 |先试用 SMCRv2 设备 | |-> conn->lgr分配已存在的 SMCRv2 链接组| |-> conn->link分配已存在的 SMCRv2 链接SMC_LGR_SYMMETRIC 中的 link_idx 可能为 1 | |-> sndbuf 和 RM 创建失败退出| |然后试用 SMCRv1 设备 | |-> conn->lgr创建 SMCRv1 链接组并分配| |-> conn->link错误地保留 SMCRv2 链接| |-> sndbuf 和RMB 创建成功仅限RMB->mr[link_idx = 0] |已初始化。 | | |则 smc_clc_send_confirm_accept() 访问conn->rmb_desc->mr[conn->link->link_idx即 1]然后崩溃。
    v 此修补程序尝试通过在分配链接之前清除 conn->lnk 来修复此问题。此外如果在创建或注册缓冲区时尝试 SMCRv2 失败最好重置连接并清理分配的资源。 (CVE-2023-53382)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - net/smc嘗試使用 SMCRv2 失敗時重設連線。我們發現搭配 2 Mellanox ConnectX-4 使用 SMCRv2 時會當機。- smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> 錯誤核心 NULL 指標解除參照位址0000000000000014 #PF在核心模式中有監督讀取存取權PFerror_code(0x0000) - 不存在頁面 PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops0000 [#1] PREEMPT SMP PTI CPU4 PID2441 Commkworker/4:249 Kdump 已載入污染GWE。 -rc1+ #42 工作佇列smc_hs_wq smc_listen_work [smc] RIP
    0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP0018:ffffb8294b2d7c78 EFLAGS00010a06 RAX
    ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10:
     R110000000000000400  : 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: 0000000000000000600003:
    00000000fffe0ff0 DR70000000000000400 呼叫追踪 <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> 在 CLC 交握期間伺服器會依序嘗試 smc_listen_work() 中可用的 SMCRv2 和 SMCRv1 裝置。找到 SMCRv2 裝置時。SMCv2 型連結群組和連結將會指派給連線。然後假設稍後在 CLC 交握中發生某些緩衝區指派錯誤例如RMB 註冊失敗伺服器將放棄 SMCRv2 並改為嘗試 SMCRv1 裝置。但係統不會重設指派給連線的資源。伺服器嘗試 SMCRv1 裝置時會再次執行連線建立處理程序。由於在嘗試 SMCRv2 時已指派 conn->lnk因此不會將其設定至 smcr_lgr_conn_assign_link() 中的正確 SMCRv1 連結。因此在這種情況下conn->lgr 會指向更正的 SMCRv1 連結群組但 conn->lnk 卻錯誤地指向 SMCRv2 連結。然後在 smc_clc_send_confirm_accept() 中會存取 conn->rmb_desc->mr[link->link_idx]。由於 link->link_idx 不正確相關 MR 可能尚未初始化因而發生損毀。 |請先嘗試 SMCRv2 裝置|-> conn->lgr指派現有的 SMCRv2 連結群組| |-> conn->link指派現有的 SMCRv2 連結 (SMC_LGR_SYMMETRIC 中的 link_idx 可能為 1) | |-> sndbuf &RMB 建立失敗結束| |然後嘗試 SMCRv1 裝置 | |-> conn->lgr建立 SMCRv1 連結群組並指派| |-> conn->link錯誤地保留 SMCRv2 連結| |-> sndbuf &RMB 建立成功僅RMB->mr[link_idx = 0] |初始化。 | |然後 smc_clc_send_confirm_accept() 存取 | conn->rmb_desc->mr[conn->link->link_idx, 這是 1]然後當機。
    v 此修補程式嘗試透過在指派連結前清除 conn->lnk 來修正此問題。此外如果在緩衝區建立或註冊過程中嘗試 SMCRv2 失敗最好重設連線並清除指派的資源。 (CVE-2023-53382)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - net/smcSMCRv2 を使用しようとする際に接続のリセットが失敗します。2 Mellanox ConnectX-4 で SMCRv2 を使用する際のクラッシュが見つかりました。これは以下により発生させることができます - smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> バグカーネル NULL ポインターデリファレンス、アドレス 0000000000000014 #PFカーネルモードのスーパーバイザー読み取りアクセス # PFerror_code(0x0000) - 存在しないページ PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops 0000 [#1] PREEMPT SMP PTI CPU 4 PID 2441 Comm kworker/4:249 Kdump 読み込み済み Tainted は GWE 4 を読み込みました。 -rc1+ #42 Workqueuesmc_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:
     R110000000000000400  : 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: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    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> CLC ハンドシェイク中に、サーバーは smc_listen_work() の利用可能な SMCRv2 および SMCRv1 デバイスを順番に試行します。SMCRv2 デバイスが見つかった場合SMCv2 ベースのリンクグループとリンクが接続に割り当てられます。RMB 登録エラーなどのいくつかのバッファ割り当てエラーが CLC ハンドシェイクで後に発生すると想定すると、サーバーは SMCRv2 を諦め、代わりに SMCRv1 デバイスを試行します。ただし、接続に割り当てられたリソースはリセットされません。サーバーが SMCRv1 デバイスを試行するとき、接続作成プロセスが再び実行されます。SMCRv2 を試行する際に conn->lnk が割り当てられているため、smcr_lgr_conn_assign_link() で正しい SMCRv1 リンクに設定されません。そのため、このような状況では、conn->lgr は正しい SMCRv1 リンクグループを指していますが、conn->lnk は誤って SMCRv2 リンクを指しています。次にsmc_clc_send_confirm_accept()で、conn->rmb_desc->mr[link->link_idx]がアクセスされます。link->link_idx が正しくないため、関連する MR が初期化されていない可能性があるため、クラッシュが発生します。 | SMCRv2 デバイスを初めて試行します | |-> conn->lgr既存の SMCRv2 リンクグループを割り当てます。 | |-> conn->link既存の SMCRv2 リンクを割り当てますlink_idx は SMC_LGR_SYMMETLIC で 1 の可能性があります| |-> sndbuf & RMB 作成が失敗し、終了します| | SMCRv1 デバイスをその後に試行します | |-> conn->lgrSMCRv1 リンクグループを作成し、割り当てます。 | |-> conn->linkSMCRv2 リンクを誤って保持します。 | |-> sndbuf と RMB の作成が成功します。RMB->mr[link_idx = 0] のみ |サービス拒否攻撃を引き起こす可能性があります。 | |次に、smc_clc_send_confirm_accept() が | にアクセスするようにします。 conn->rmb_desc->mr[conn->link->link_idx (1)] の場合、クラッシュします。
    v このパッチは、リンクを割り当てる前に conn->lnk を消去することでこれの修正を試みます。また、SMCRv2 の試行がバッファの作成または登録で失敗した場合は、接続をリセットして割り当てられたリソースをクリーンすることをお勧めします。CVE-2023-53382

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-005406 advisory.

    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. It     can 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 SMCRv2     and SMCRv1 devices in smc_listen_work().

    If an SMCRv2 device is found. SMCv2 based link group and link will be     assigned to the connection. Then assumed that some buffer assignment     errors happen later in the CLC handshake, such as RMB registration     failure, server will give up SMCRv2 and try SMCRv1 device instead. But     the resources assigned to the connection won't be reset.

    When server tries SMCRv1 device, the connection creation process will     be executed again. Since conn->lnk has been assigned when trying SMCRv2,     it will not be set to the correct SMCRv1 link in     smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to     correct SMCRv1 link group but conn->lnk points to the SMCRv2 link     mistakenly.

    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 related     MR 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.
     v

    This patch tries to fix this by cleaning conn->lnk before assigning     link. In addition, it is better to reset the connection and clean the     resources assigned if trying SMCRv2 failed in buffer creation or     registration.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - net/smc: Reset connection when trying to use SMCRv2 fails. We found a crash when using SMCRv2 with 2     Mellanox ConnectX-4. It can 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 SMCRv2 and     SMCRv1 devices in smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be     assigned to the connection. Then assumed that some buffer assignment errors happen later in the CLC     handshake, such as RMB registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But     the resources assigned to the connection won't be reset. When server tries SMCRv1 device, the connection     creation process will be executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not     be set to the correct SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points     to correct SMCRv1 link group but conn->lnk points to the SMCRv2 link mistakenly. 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 related MR 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.
    v This patch tries to fix this by cleaning conn->lnk before assigning link. In addition, it is better to     reset the connection and clean the resources assigned if trying SMCRv2 failed in buffer creation or     registration. (CVE-2023-53382)

Note that Nessus relies on the presence of the package as reported by the vendor.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-013656 advisory.

    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. It     can 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 SMCRv2     and SMCRv1 devices in smc_listen_work().

    If an SMCRv2 device is found. SMCv2 based link group and link will be     assigned to the connection. Then assumed that some buffer assignment     errors happen later in the CLC handshake, such as RMB registration     failure, server will give up SMCRv2 and try SMCRv1 device instead. But     the resources assigned to the connection won't be reset.

    When server tries SMCRv1 device, the connection creation process will     be executed again. Since conn->lnk has been assigned when trying SMCRv2,     it will not be set to the correct SMCRv1 link in     smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to     correct SMCRv1 link group but conn->lnk points to the SMCRv2 link     mistakenly.

    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 related     MR 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.
     v

    This patch tries to fix this by cleaning conn->lnk before assigning     link. In addition, it is better to reset the connection and clean the     resources assigned if trying SMCRv2 failed in buffer creation or     registration.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
265599	Linux Distros 未修补的漏洞：CVE-2023-53382	Nessus	Misc.	2025/9/20	2026/2/6	medium
265599	Linux Distros 未修補的弱點：CVE-2023-53382	Nessus	Misc.	2025/9/20	2026/2/6	medium
265599	Linux Distros のパッチ未適用の脆弱性: CVE-2023-53382	Nessus	Misc.	2025/9/20	2026/2/6	medium
300312	Unity Linux 20.1070e Security Update: kernel (UTSA-2026-005406)	Nessus	Unity Linux Local Security Checks	2026/3/3	2026/3/3	medium
265599	Linux Distros Unpatched Vulnerability : CVE-2023-53382	Nessus	Misc.	2025/9/20	2026/2/6	medium
309490	Unity Linux 20.1070a Security Update: kernel (UTSA-2026-013656)	Nessus	Unity Linux Local Security Checks	2026/4/22	2026/4/22	medium

检测

插件搜索

medium

medium

medium

medium

medium

medium