CVE-2023-53591
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-04

Last updated on: 2026-03-21

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix deadlock in tc route query code Cited commit causes ABBA deadlock[0] when peer flows are created while holding the devcom rw semaphore. Due to peer flows offload implementation the lock is taken much higher up the call chain and there is no obvious way to easily fix the deadlock. Instead, since tc route query code needs the peer eswitch structure only to perform a lookup in xarray and doesn't perform any sleeping operations with it, refactor the code for lockless execution in following ways: - RCUify the devcom 'data' pointer. When resetting the pointer synchronously wait for RCU grace period before returning. This is fine since devcom is currently only used for synchronization of pairing/unpairing of eswitches which is rare and already expensive as-is. - Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has already been used in some unlocked contexts without proper annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't an issue since all relevant code paths checked it again after obtaining the devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as "best effort" check to return NULL when devcom is being unpaired. Note that while RCU read lock doesn't prevent the unpaired flag from being changed concurrently it still guarantees that reader can continue to use 'data'. - Refactor mlx5e_tc_query_route_vport() function to use new mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock. [0]: [ 164.599612] ====================================================== [ 164.600142] WARNING: possible circular locking dependency detected [ 164.600667] 6.3.0-rc3+ #1 Not tainted [ 164.601021] ------------------------------------------------------ [ 164.601557] handler1/3456 is trying to acquire lock: [ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.603078] but task is already holding lock: [ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.604459] which lock already depends on the new lock. [ 164.605190] the existing dependency chain (in reverse order) is: [ 164.605848] -> #1 (&comp->sem){++++}-{3:3}: [ 164.606380] down_read+0x39/0x50 [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core] [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core] [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core] [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core] [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core] [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core] [ 164.610741] tc_setup_cb_add+0xd4/0x200 [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower] [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower] [ 164.612116] tc_new_tfilter+0x3fc/0xd20 [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0 [ 164.612936] netlink_rcv_skb+0x54/0x100 [ 164.613339] netlink_unicast+0x190/0x250 [ 164.613746] netlink_sendmsg+0x245/0x4a0 [ 164.614150] sock_sendmsg+0x38/0x60 [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0 [ 164.614934] ___sys_sendmsg+0x80/0xc0 [ 164.615320] __sys_sendmsg+0x51/0x90 [ 164.615701] do_syscall_64+0x3d/0x90 [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}: [ 164.617210] __lock_acquire+0x159e/0x26e0 [ 164.617638] lock_acquire+0xc2/0x2a0 [ 164.618018] __mutex_lock+0x92/0xcd0 [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.618943] post_process_attr+0x153/0x2d0 [ ---truncated---
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-04
Last Modified
2026-03-21
Generated
2026-05-07
AI Q&A
2025-10-04
EPSS Evaluated
2026-05-05
NVD
CVE-2023-53591
EUVD
EUVD-2025-32308
Affected Vendors & Products
Showing 7 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.4
linux linux_kernel 6.4
linux linux_kernel 6.4
linux linux_kernel From 5.13.17 (inc) to 5.14 (exc)
linux linux_kernel From 6.2 (inc) to 6.3.5 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.31 (exc)
linux linux_kernel From 5.14.4 (inc) to 5.15.115 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-667 The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a deadlock issue in the Linux kernel's mlx5e network driver, specifically in the tc route query code. The problem arises due to a circular locking dependency (ABBA deadlock) when peer flows are created while holding a read-write semaphore. The deadlock occurs because the lock is taken higher up the call chain and the existing code paths do not handle this properly. The fix involves refactoring the code to use lockless execution techniques such as RCU (Read-Copy-Update) for accessing shared data and proper atomic operations for boolean flags, thereby avoiding the deadlock scenario.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to deadlock when handling certain network flow operations involving the mlx5e driver. A deadlock means that affected processes or kernel threads may hang indefinitely, potentially leading to degraded network performance, stalled network traffic, or system instability on systems using this driver and feature set.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring the system logs for warnings about circular locking dependencies or deadlocks related to mlx5_core, specifically messages similar to 'WARNING: possible circular locking dependency detected' involving mlx5e_attach_encap and mlx5_devcom_get_peer_data. You can check the kernel logs using commands like 'dmesg | grep mlx5_core' or 'journalctl -k | grep mlx5_core' to look for such warnings.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version that includes the fix for this deadlock issue in the mlx5e tc route query code. The fix refactors the code to avoid the deadlock by using lockless execution techniques. Until the update is applied, monitoring for deadlock symptoms and avoiding workloads that trigger peer flow creation while holding the devcom rw semaphore may reduce the risk.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart