CVE-2024-36003

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix LAG and VF lock dependency in ice_reset_vf()<br /> <br /> 9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over<br /> aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf().<br /> The commit placed this lock acquisition just prior to the acquisition of<br /> the VF configuration lock.<br /> <br /> If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK<br /> flag, this could deadlock with ice_vc_cfg_qs_msg() because it always<br /> acquires the locks in the order of the VF configuration lock and then the<br /> LAG mutex.<br /> <br /> Lockdep reports this violation almost immediately on creating and then<br /> removing 2 VF:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.8.0-rc6 #54 Tainted: G W O<br /> ------------------------------------------------------<br /> kworker/60:3/6771 is trying to acquire lock:<br /> ff40d43e099380a0 (&amp;vf-&gt;cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]<br /> <br /> but task is already holding lock:<br /> ff40d43ea1961210 (&amp;pf-&gt;lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (&amp;pf-&gt;lag_mutex){+.+.}-{3:3}:<br /> __lock_acquire+0x4f8/0xb40<br /> lock_acquire+0xd4/0x2d0<br /> __mutex_lock+0x9b/0xbf0<br /> ice_vc_cfg_qs_msg+0x45/0x690 [ice]<br /> ice_vc_process_vf_msg+0x4f5/0x870 [ice]<br /> __ice_clean_ctrlq+0x2b5/0x600 [ice]<br /> ice_service_task+0x2c9/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> kthread+0x104/0x140<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> -&gt; #0 (&amp;vf-&gt;cfg_lock){+.+.}-{3:3}:<br /> check_prev_add+0xe2/0xc50<br /> validate_chain+0x558/0x800<br /> __lock_acquire+0x4f8/0xb40<br /> lock_acquire+0xd4/0x2d0<br /> __mutex_lock+0x9b/0xbf0<br /> ice_reset_vf+0x22f/0x4d0 [ice]<br /> ice_process_vflr_event+0x98/0xd0 [ice]<br /> ice_service_task+0x1cc/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> kthread+0x104/0x140<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;pf-&gt;lag_mutex);<br /> lock(&amp;vf-&gt;cfg_lock);<br /> lock(&amp;pf-&gt;lag_mutex);<br /> lock(&amp;vf-&gt;cfg_lock);<br /> <br /> *** DEADLOCK ***<br /> 4 locks held by kworker/60:3/6771:<br /> #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0<br /> #1: ff50d06e05197e58 ((work_completion)(&amp;pf-&gt;serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0<br /> #2: ff40d43ea1960e50 (&amp;pf-&gt;vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]<br /> #3: ff40d43ea1961210 (&amp;pf-&gt;lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]<br /> <br /> stack backtrace:<br /> CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54<br /> Hardware name:<br /> Workqueue: ice ice_service_task [ice]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4a/0x80<br /> check_noncircular+0x12d/0x150<br /> check_prev_add+0xe2/0xc50<br /> ? save_trace+0x59/0x230<br /> ? add_chain_cache+0x109/0x450<br /> validate_chain+0x558/0x800<br /> __lock_acquire+0x4f8/0xb40<br /> ? lockdep_hardirqs_on+0x7d/0x100<br /> lock_acquire+0xd4/0x2d0<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? lock_is_held_type+0xc7/0x120<br /> __mutex_lock+0x9b/0xbf0<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? rcu_is_watching+0x11/0x50<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? process_one_work+0x176/0x4d0<br /> ice_process_vflr_event+0x98/0xd0 [ice]<br /> ice_service_task+0x1cc/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x104/0x140<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> To avoid deadlock, we must acquire the LAG <br /> ---truncated---