{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2023-53591 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2023-53591 is a medium-severity vulnerability in Linux kernel, published on 4 Oct 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2023-53591 and fix it if it is affected.\n\nWhat it is: CVE-2023-53591 is a medium-severity vulnerability in Linux kernel, published on 4 Oct 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2023-53591 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2023-53591/ (Markdown: https://insights.sbomify.com/CVE-2023-53591/index.md)","id":"CVE-2023-53591","markdown":"https://insights.sbomify.com/CVE-2023-53591/index.md","name":"CVE-2023-53591","record":{"aliases":["BELL-CVE-2023-53591","DEBIAN-CVE-2023-53591","GHSA-8qq6-88xp-8ghp","UBUNTU-CVE-2023-53591"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel driver","requires_auth":"low_privilege","summary":"A deadlock in the Linux kernel mlx5e driver can cause a denial of service when creating peer flows.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-667","name":"Improper Locking"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix deadlock in tc route query code\n\nCited commit causes ABBA deadlock[0] when peer flows are created while\nholding the devcom rw semaphore. Due to peer flows offload implementation\nthe lock is taken much higher up the call chain and there is no obvious way\nto easily fix the deadlock. Instead, since tc route query code needs the\npeer eswitch structure only to perform a lookup in xarray and doesn't\nperform any sleeping operations with it, refactor the code for lockless\nexecution in following ways:\n\n- RCUify the devcom 'data' pointer. When resetting the pointer\nsynchronously wait for RCU grace period before returning. This is fine\nsince devcom is currently only used for synchronization of\npairing/unpairing of eswitches which is rare and already expensive as-is.\n\n- Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has\nalready been used in some unlocked contexts without proper\nannotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't\nan issue since all relevant code paths checked it again after obtaining the\ndevcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as\n\"best effort\" check to return NULL when devcom is being unpaired. Note that\nwhile RCU read lock doesn't prevent the unpaired flag from being changed\nconcurrently it still guarantees that reader can continue to use 'data'.\n\n- Refactor mlx5e_tc_query_route_vport() function to use new\nmlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.\n\n[0]:\n\n[  164.599612] ======================================================\n[  164.600142] WARNING: possible circular locking dependency detected\n[  164.600667] 6.3.0-rc3+ #1 Not tainted\n[  164.601021] ------------------------------------------------------\n[  164.601557] handler1/3456 is trying to acquire lock:\n[  164.601998] ffff88811f1714b0 (\u0026esw-\u003eoffloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]\n[  164.603078]\n               but task is already holding lock:\n[  164.603617] ffff88810137fc98 (\u0026comp-\u003esem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]\n[  164.604459]\n               which lock already depends on the new lock.\n\n[  164.605190]\n               the existing dependency chain (in reverse order) is:\n[  164.605848]\n               -\u003e #1 (\u0026comp-\u003esem){++++}-{3:3}:\n[  164.606380]        down_read+0x39/0x50\n[  164.606772]        mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]\n[  164.607336]        mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core]\n[  164.607914]        mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core]\n[  164.608495]        mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core]\n[  164.609063]        mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core]\n[  164.609627]        __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core]\n[  164.610175]        mlx5e_configure_flower+0x952/0x1a20 [mlx5_core]\n[  164.610741]        tc_setup_cb_add+0xd4/0x200\n[  164.611146]        fl_hw_replace_filter+0x14c/0x1f0 [cls_flower]\n[  164.611661]        fl_change+0xc95/0x18a0 [cls_flower]\n[  164.612116]        tc_new_tfilter+0x3fc/0xd20\n[  164.612516]        rtnetlink_rcv_msg+0x418/0x5b0\n[  164.612936]        netlink_rcv_skb+0x54/0x100\n[  164.613339]        netlink_unicast+0x190/0x250\n[  164.613746]        netlink_sendmsg+0x245/0x4a0\n[  164.614150]        sock_sendmsg+0x38/0x60\n[  164.614522]        ____sys_sendmsg+0x1d0/0x1e0\n[  164.614934]        ___sys_sendmsg+0x80/0xc0\n[  164.615320]        __sys_sendmsg+0x51/0x90\n[  164.615701]        do_syscall_64+0x3d/0x90\n[  164.616083]        entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[  164.616568]\n               -\u003e #0 (\u0026esw-\u003eoffloads.encap_tbl_lock){+.+.}-{3:3}:\n[  164.617210]        __lock_acquire+0x159e/0x26e0\n[  164.617638]        lock_acquire+0xc2/0x2a0\n[  164.618018]        __mutex_lock+0x92/0xcd0\n[  164.618401]        mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]\n[  164.618943]        post_process_attr+0x153/0x2d0 [\n---truncated---","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"net/mlx5e: Fix deadlock in tc route query code","id":"CVE-2023-53591","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"race_condition","year":"2023"},"n_packages":0,"n_references":4,"next":{"headline":"gpio: sifive: Fix refcount leak in sifive_gpio_probe","id":"CVE-2023-53592"},"packages":[],"prev":{"headline":"sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop","id":"CVE-2023-53590"},"products":["Linux"],"published":"2025-10-04","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-23","vendors":["Linux"]},"summary":"A deadlock in the Linux kernel mlx5e driver can cause a denial of service when creating peer flows.","url":"https://insights.sbomify.com/CVE-2023-53591/"}