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

  - 已解決 Linux 核心中的下列弱點：net/smc: fix deadlock triggered by cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted
    ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock:
    00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0
    __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8
    __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150
    __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at:
    process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated--- (CVE-2023-53233)

請注意，Nessus 依賴供應商報告的套件存在。

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

  - 已修复 Linux 内核中的下列漏洞：net/smc: fix deadlock triggered by cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted
    ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock:
    00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0
    __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8
    __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150
    __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at:
    process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated--- (CVE-2023-53233)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: net/smc: fix deadlock triggered by cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted
    ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock:
    00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0
    __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8
    __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150
    __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at:
    process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated--- (CVE-2023-53233)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: net/smc: fix deadlock triggered by     cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc]     WARNING: possible circular locking dependency detected     6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted
    ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock:
    00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but     task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0},     at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain     (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0
    __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418     [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3     (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248     lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418     [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-     AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8     lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730     worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1     ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8     lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730     worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0     ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8
    __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8     smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150
    __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists     of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending -->     (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ----     lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion)     (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by     kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at:
    process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion)     (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated---     (CVE-2023-53233)

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

An update of the linux package has been released.

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

    In the Linux kernel, the following vulnerability has been resolved:

    net/smc: fix deadlock triggered by cancel_delayed_work_syn()

    The following LOCKDEP was detected:
                    Workqueue: events smc_lgr_free_work [smc]                     WARNING: possible circular locking dependency detected                     6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted
                    ------------------------------------------------------                     kworker/3:0/176251 is trying to acquire lock:
                    00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0},                             at: __flush_workqueue+0x7a/0x4f0                     but task is already holding lock:
                    0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0},                             at: process_one_work+0x232/0x730                     which lock already depends on the new lock.
                    the existing dependency chain (in reverse order) is:
                    -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8
                           __flush_work+0x76/0xf0
                           __cancel_work_timer+0x170/0x220
                           __smc_lgr_terminate.part.0+0x34/0x1c0 [smc]                            smc_connect_rdma+0x15e/0x418 [smc]
                           __smc_connect+0x234/0x480 [smc]                            smc_connect+0x1d6/0x230 [smc]
                           __sys_connect+0x90/0xc0
                           __do_sys_socketcall+0x186/0x370
                           __do_syscall+0x1da/0x208                            system_call+0x82/0xb0
                    -> #3 (smc_client_lgr_pending){+.+.}-{3:3}:
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8
                           __mutex_lock+0x96/0x8e8                            mutex_lock_nested+0x32/0x40                            smc_connect_rdma+0xa4/0x418 [smc]
                           __smc_connect+0x234/0x480 [smc]                            smc_connect+0x1d6/0x230 [smc]
                           __sys_connect+0x90/0xc0
                           __do_sys_socketcall+0x186/0x370
                           __do_syscall+0x1da/0x208                            system_call+0x82/0xb0
                    -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8                            lock_sock_nested+0x46/0xa8                            smc_tx_work+0x34/0x50 [smc]                            process_one_work+0x30c/0x730                            worker_thread+0x62/0x420                            kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58                            ret_from_fork+0xa/0x40
                    -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8                            process_one_work+0x2bc/0x730                            worker_thread+0x62/0x420                            kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58                            ret_from_fork+0xa/0x40
                    -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}:
                           check_prev_add+0xd8/0xe88                            validate_chain+0x70c/0xb20
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8
                           __flush_workqueue+0xaa/0x4f0                            drain_workqueue+0xaa/0x158                            destroy_workqueue+0x44/0x2d8                            smc_lgr_free+0x9e/0xf8 [smc]                            process_one_work+0x30c/0x730                            worker_thread+0x62/0x420                            kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58                            ret_from_fork+0xa/0x40                     other info that might help us debug this:
                    Chain exists of:
                      (wq_completion)smc_tx_wq-00000000#2
                      --> smc_client_lgr_pending
                      --> (work_completion)(&(&lgr->free_work)->work)                      Possible unsafe locking scenario:
                           CPU0                    CPU1
                           ----                    ----                       lock((work_completion)(&(&lgr->free_work)->work));
                                       lock(smc_client_lgr_pending);
                                       lock((work_completion)                                             (&(&lgr->free_work)->work));
                      lock((wq_completion)smc_tx_wq-00000000#2);
                     *** DEADLOCK ***                     2 locks held by kworker/3:0/176251:
                     #0: 0000000080183548                             ((wq_completion)events){+.+.}-{0:0},                                     at: process_one_work+0x232/0x730                      #1: 0000037fffe97dc8                             ((work_completion)                              (&(&lgr->free_work)->work)){+.+.}-{0:0},                                     at: process_one_work+0x232/0x730                     stack backtr
    ---truncated---

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 Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-992554 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    net/smc: fix deadlock triggered by cancel_delayed_work_syn()

    The following LOCKDEP was detected:
                    Workqueue: events smc_lgr_free_work [smc]                     WARNING: possible circular locking dependency detected                     6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted
                    ------------------------------------------------------                     kworker/3:0/176251 is trying to acquire lock:
                    00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0},                             at: __flush_workqueue+0x7a/0x4f0                     but task is already holding lock:
                    0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0},                             at: process_one_work+0x232/0x730                     which lock already depends on the new lock.
                    the existing dependency chain (in reverse order) is:
                    -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8
                           __flush_work+0x76/0xf0
                           __cancel_work_timer+0x170/0x220
                           __smc_lgr_terminate.part.0+0x34/0x1c0 [smc]                            smc_connect_rdma+0x15e/0x418 [smc]
                           __smc_connect+0x234/0x480 [smc]                            smc_connect+0x1d6/0x230 [smc]
                           __sys_connect+0x90/0xc0
                           __do_sys_socketcall+0x186/0x370
                           __do_syscall+0x1da/0x208                            system_call+0x82/0xb0
                    -> #3 (smc_client_lgr_pending){+.+.}-{3:3}:
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8
                           __mutex_lock+0x96/0x8e8                            mutex_lock_nested+0x32/0x40                            smc_connect_rdma+0xa4/0x418 [smc]
                           __smc_connect+0x234/0x480 [smc]                            smc_connect+0x1d6/0x230 [smc]
                           __sys_connect+0x90/0xc0
                           __do_sys_socketcall+0x186/0x370
                           __do_syscall+0x1da/0x208                            system_call+0x82/0xb0
                    -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8                            lock_sock_nested+0x46/0xa8                            smc_tx_work+0x34/0x50 [smc]                            process_one_work+0x30c/0x730                            worker_thread+0x62/0x420                            kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58                            ret_from_fork+0xa/0x40
                    -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}:
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8                            process_one_work+0x2bc/0x730                            worker_thread+0x62/0x420                            kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58                            ret_from_fork+0xa/0x40
                    -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}:
                           check_prev_add+0xd8/0xe88                            validate_chain+0x70c/0xb20
                           __lock_acquire+0x58e/0xbd8                            lock_acquire.part.0+0xe2/0x248                            lock_acquire+0xac/0x1c8
                           __flush_workqueue+0xaa/0x4f0                            drain_workqueue+0xaa/0x158                            destroy_workqueue+0x44/0x2d8                            smc_lgr_free+0x9e/0xf8 [smc]                            process_one_work+0x30c/0x730                            worker_thread+0x62/0x420                            kthread+0x138/0x150
                           __ret_from_fork+0x3c/0x58                            ret_from_fork+0xa/0x40                     other info that might help us debug this:
                    Chain exists of:
                      (wq_completion)smc_tx_wq-00000000#2
                      --> smc_client_lgr_pending
                      --> (work_completion)(&(&lgr->free_work)->work)                      Possible unsafe locking scenario:
                           CPU0                    CPU1
                           ----                    ----                       lock((work_completion)(&(&lgr->free_work)->work));
                                       lock(smc_client_lgr_pending);
                                       lock((work_completion)                                             (&(&lgr->free_work)->work));
                      lock((wq_completion)smc_tx_wq-00000000#2);
                     *** DEADLOCK ***                     2 locks held by kworker/3:0/176251:
                     #0: 0000000080183548                             ((wq_completion)events){+.+.}-{0:0},                                     at: process_one_work+0x232/0x730                      #1: 0000037fffe97dc8                             ((work_completion)                              (&(&lgr->free_work)->work)){+.+.}-{0:0},                                     at: process_one_work+0x232/0x730                     stack backtr
    ---truncated---

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	名称	产品	系列	发布时间	最近更新时间	严重程度
264938	Linux Distros 未修補的弱點：CVE-2023-53233	Nessus	Misc.	2025/9/16	2026/3/7	medium
264938	Linux Distros 未修补的漏洞：CVE-2023-53233	Nessus	Misc.	2025/9/16	2026/3/7	medium
264938	Linux Distros のパッチ未適用の脆弱性: CVE-2023-53233	Nessus	Misc.	2025/9/16	2026/3/7	medium
264938	Linux Distros Unpatched Vulnerability : CVE-2023-53233	Nessus	Misc.	2025/9/16	2026/3/7	medium
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	2021/7/22	2026/3/23	high
280914	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2025-993266)	Nessus	Unity Linux Local Security Checks	2025/12/31	2025/12/31	medium
280408	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2025-992554)	Nessus	Unity Linux Local Security Checks	2025/12/30	2025/12/30	medium

检测

插件搜索

medium

medium

medium

medium

high

medium

medium