CVE-2023-53233

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