{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-27435", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-27435" ], "published": "2024-05-17T12:13:20Z", "summary": "nvme: fix reconnection fail due to reserved tag allocation", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix reconnection fail due to reserved tag allocation\n\nWe found a issue on production environment while using NVMe over RDMA,\nadmin_q reconnect failed forever while remote target and network is ok.\nAfter dig into it, we found it may caused by a ABBA deadlock due to tag\nallocation. In my case, the tag was hold by a keep alive request\nwaiting inside admin_q, as we quiesced admin_q while reset ctrl, so the\nrequest maked as idle and will not process before reset success. As\nfabric_q shares tagset with admin_q, while reconnect remote target, we\nneed a tag for connect command, but the only one reserved tag was held\nby keep alive command which waiting inside admin_q. As a result, we\nfailed to reconnect admin_q forever. In order to fix this issue, I\nthink we should keep two reserved tags for admin queue.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.21-1+rpt1", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1", "1:6.6.20-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7l", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7l", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7l", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7l", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83" }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83", "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83" }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83" }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.83" }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.83" }, "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.23" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-27435" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ff2f90f88d78559802466ad1c84ac5bda4416b3a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6851778504cdb49431809b4ba061903d5f592c96" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/de105068fead55ed5c07ade75e9c8e7f86a00d1d" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.5, "cvss_v3_severity": "High", "scenario": "AV:N - The affected code is the NVMe-over-Fabrics host driver (nvme-tcp/nvme-rdma/nvme-fc), and the controller reset that opens the race window is triggered directly from remote peer input \u2014 `nvme_tcp_state_change()` fires error recovery on a peer FIN/RST, and the receive path calls `nvme_tcp_error_recovery()` on any malformed PDU. A remote or on-path attacker against the NVMe/TCP connection (port 4420) can drive the vulnerable path without local access.\nAC:L - The attacker controls the reset side of the race and can force error recovery/reconnect cycles arbitrarily many times (reconnect re-arms the keep-alive timer each round), while the keep-alive period is deterministic at kato/2, so the window can be hit by retry and by timing; the bug was also observed occurring spontaneously in production. Once won, the leaked reserved tag is permanent \u2014 no further conditions are needed.\nPR:N - No credentials on the victim host are required \u2014 the triggering events (TCP FIN/RST, malformed NVMe/TCP PDU, unresponsive target) are handled by `nvme_tcp_state_change()` and the recv path before or independent of any NVMe-level authentication, and NVMe/TCP deployments commonly run with no DH-HMAC-CHAP or TLS at all.\nUI:N - Exploitation requires no action from any user or administrator; an already-established NVMe-oF connection is a system configuration precondition, not victim interaction, and the keep-alive/reset machinery runs autonomously in kernel workqueues.\nS:U - The impact is confined to the kernel and the host's own storage stack \u2014 no security authority boundary such as a VM, IOMMU, or sandbox is crossed.\nC:N - The defect is a reserved-tag leak causing an ABBA allocation deadlock; no memory is read out of bounds, no freed object is accessed, and no kernel data is disclosed to the attacker.\nI:N - There is no memory corruption, out-of-bounds write, or control-flow primitive \u2014 the only consequence is that a blk-mq tag is never returned, so no attacker-influenced data modification is possible.\nA:H - The admin queue can never reconnect (\"failed to reconnect admin_q forever\"), because the admin tagset is not reallocated on reconnect and the connect command's reserved tag allocation fails with -EAGAIN indefinitely, producing a permanent loss of the NVMe-oF storage path plus eventual controller deletion (and a hung, unkillable teardown worker blocked on queue freeze) \u2014 total availability loss for storage that is frequently the system's root or primary data volume." } } }