GPU VulnDB

Database/Firmware, BMC & network fabric

Linux nvme-rdma: admin queue left quiesced on setup failure, hanging the task that destroys it

CVSS 5.7CVE-2024-49569Firmware, BMC & network fabriccurated

Impact

When nvme_rdma_setup_ctrl() fails, the admin queue is quiesced to cancel requests but never unquiesced before destruction, so blk_mq_freeze_queue_wait() never completes and the thread doing the connect hangs in D state forever. For an operator this is an unkillable task plus an NVMe-oF target that will not attach - on nodes that mount model or dataset storage over NVMe/RDMA, a target that flaps during connect can wedge the storage path and the stuck freeze typically survives any retry, so the node has to be rebooted. Availability only: no memory disclosure or privilege gain, and it needs a failing controller setup to reach.

Who can reach it

Local user able to write to /dev/nvme-fabrics (normally root or a storage automation agent), or an adjacent NVMe-oF target on the fabric that fails controller creation. CVSS records it as adjacent-network with low privileges.

What to do

Update to a stable kernel that reuses nvme_rdma_teardown_admin_queue() on the failure path and reboot the node. The nvme_rdma module can be reloaded instead if no NVMe-oF namespaces are in use, but a node with a hung freeze will not unload it - plan a drain and reboot. Only kernel.org commits are given as fixes.

References

Related entries

All Firmware, BMC & network fabric entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.