CVE-2023-53591

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix deadlock in tc route query code<br /> <br /> Cited commit causes ABBA deadlock[0] when peer flows are created while<br /> holding the devcom rw semaphore. Due to peer flows offload implementation<br /> the lock is taken much higher up the call chain and there is no obvious way<br /> to easily fix the deadlock. Instead, since tc route query code needs the<br /> peer eswitch structure only to perform a lookup in xarray and doesn&amp;#39;t<br /> perform any sleeping operations with it, refactor the code for lockless<br /> execution in following ways:<br /> <br /> - RCUify the devcom &amp;#39;data&amp;#39; pointer. When resetting the pointer<br /> synchronously wait for RCU grace period before returning. This is fine<br /> since devcom is currently only used for synchronization of<br /> pairing/unpairing of eswitches which is rare and already expensive as-is.<br /> <br /> - Wrap all usages of &amp;#39;paired&amp;#39; boolean in {READ|WRITE}_ONCE(). The flag has<br /> already been used in some unlocked contexts without proper<br /> annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn&amp;#39;t<br /> an issue since all relevant code paths checked it again after obtaining the<br /> devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as<br /> "best effort" check to return NULL when devcom is being unpaired. Note that<br /> while RCU read lock doesn&amp;#39;t prevent the unpaired flag from being changed<br /> concurrently it still guarantees that reader can continue to use &amp;#39;data&amp;#39;.<br /> <br /> - Refactor mlx5e_tc_query_route_vport() function to use new<br /> mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.<br /> <br /> [0]:<br /> <br /> [ 164.599612] ======================================================<br /> [ 164.600142] WARNING: possible circular locking dependency detected<br /> [ 164.600667] 6.3.0-rc3+ #1 Not tainted<br /> [ 164.601021] ------------------------------------------------------<br /> [ 164.601557] handler1/3456 is trying to acquire lock:<br /> [ 164.601998] ffff88811f1714b0 (&amp;esw-&gt;offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]<br /> [ 164.603078]<br /> but task is already holding lock:<br /> [ 164.603617] ffff88810137fc98 (&amp;comp-&gt;sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]<br /> [ 164.604459]<br /> which lock already depends on the new lock.<br /> <br /> [ 164.605190]<br /> the existing dependency chain (in reverse order) is:<br /> [ 164.605848]<br /> -&gt; #1 (&amp;comp-&gt;sem){++++}-{3:3}:<br /> [ 164.606380] down_read+0x39/0x50<br /> [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]<br /> [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core]<br /> [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core]<br /> [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core]<br /> [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core]<br /> [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core]<br /> [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core]<br /> [ 164.610741] tc_setup_cb_add+0xd4/0x200<br /> [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower]<br /> [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower]<br /> [ 164.612116] tc_new_tfilter+0x3fc/0xd20<br /> [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0<br /> [ 164.612936] netlink_rcv_skb+0x54/0x100<br /> [ 164.613339] netlink_unicast+0x190/0x250<br /> [ 164.613746] netlink_sendmsg+0x245/0x4a0<br /> [ 164.614150] sock_sendmsg+0x38/0x60<br /> [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0<br /> [ 164.614934] ___sys_sendmsg+0x80/0xc0<br /> [ 164.615320] __sys_sendmsg+0x51/0x90<br /> [ 164.615701] do_syscall_64+0x3d/0x90<br /> [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 164.616568]<br /> -&gt; #0 (&amp;esw-&gt;offloads.encap_tbl_lock){+.+.}-{3:3}:<br /> [ 164.617210] __lock_acquire+0x159e/0x26e0<br /> [ 164.617638] lock_acquire+0xc2/0x2a0<br /> [ 164.618018] __mutex_lock+0x92/0xcd0<br /> [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]<br /> [ 164.618943] post_process_attr+0x153/0x2d0 [<br /> ---truncated---