CVE-2023-53591

MEDIUMNVD 5.55.5—

5.5

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 v3: 5.5
EG Score: 5.5(medium)
EPSS: 2.6%
KEV: Not listed

Published

October 4, 2025

Last Modified

March 21, 2026

References (4)

416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/362063df6ceec80b0b6798b61ae03504dcc125a5
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/691c041bf20899fc13c793f92ba61ab660fa3a30
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/69966bce28da6aadccfd968b75d128a79da32d17
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a7236e420a7d8082b1df4b3e05c739dd2642a662

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

CWE-667

All Vendor Advisories

(2)

Every vendor that published an advisory referencing this CVE — pulled from our cve_vendor_advisories aggregation. Click any row for the vendor's original advisory page.

Data Freshness Timeline

(refreshed 11× in last 7d / 11× in last 30d)

Every time one of our enrichment pipelines (NVD, MITRE cvelistV5, EPSS, CISA KEV, GHSA, OSV, vendor advisories) ran against this CVE. Most recent first.

2026-06-02 20:12 UTCepss_batch
2026-06-02 20:12 UTCepss_batch
2026-06-01 13:51 UTCepss_batch
2026-05-31 22:30 UTCepss_batch
2026-05-31 22:30 UTCepss_batch
2026-05-31 00:15 UTCepss_batch
2026-05-31 00:15 UTCepss_batch
2026-05-29 21:27 UTCEG score recompute
2026-05-29 21:27 UTCVendor advisory
2026-05-29 21:27 UTCGHSA enrichment
2026-05-29 13:43 UTCepss_batch

Frequently asked(5)

What is CVE-2023-53591?

CVE-2023-53591 is a medium vulnerability published on October 4, 2025. 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…

When was CVE-2023-53591 disclosed?

CVE-2023-53591 was first published in the National Vulnerability Database on October 4, 2025, with the most recent update on March 21, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.

Is CVE-2023-53591 actively exploited?

CVE-2023-53591 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 2.6% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.

What is the CVSS score of CVE-2023-53591?

CVE-2023-53591 has a CVSS v3 base score of 5.5 (NVD).

How do I remediate CVE-2023-53591?

Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2023-53591, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2023-53591

Explore →

Is Your Infrastructure Affected by CVE-2023-53591?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.

Start Free Scan →Browse All CVEs