CVE-2023-53233: 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---