CVE-2026-90206: nvmet: fix max_qid race between configfs and controller allocation
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix maxqid race between configfs and controller allocation
The function nvmetsubsysattrqidmaxstore() can race against nvmetallocctrl() when a subsystem's maxqid limit is modified.
Suppose maxqid is currently 64. If nvmetallocctrl() executes: ctrl->sqs = kzallocobjs(struct nvmetsq , subsys->maxqid + 1); and at this exact point, a userspace process changes maxqid to 128, nvmetsubsysattrqidmaxstore() will set the new maxqid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet.
nvmetallocctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmetinstallqueue() is called, it will see maxqid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions.
Fix this by protecting the queue allocations and list insertion in nvmetallocctrl() with downread(&nvmetconfigsem). Because nvmetsubsysattrqidmaxstore() acquires downwrite(&nvmetconfigsem) to modify the attribute, this safely prevents the configfs writer from modifying maxqid during controller creation.
Copy the maxqid from the subsystem to the controller's structure during the allocation; ctrl->maxqid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
A userspace process must modify an NVMe target subsystem's max_qid setting while nvmet_alloc_ctrl() is allocating and initializing a new controller. The race requires the configuration change to occur after the controller queue-array allocation uses the old value but before the controller is inserted into the subsystem controller list.
What is the potential impact if the race occurs?
A later queue installation can use the new, larger max_qid value against an sqs array allocated for the earlier, smaller value. This causes an out-of-bounds access, reported by KASAN, and may result in memory corruption.
How can administrators reduce exposure before applying the fix?
Avoid changing a subsystem's max_qid limit while controllers may be allocated or reconnecting. Coordinate configuration changes so that no new controller allocation can overlap the max_qid update.
How can this condition be identified?
The described symptom is a KASAN out-of-bounds warning during queue installation after max_qid has been changed while a controller was being created. The relevant sequence involves an sqs allocation using an old max_qid value followed by queue handling under a newer value.