UBUNTU-CVE-2026-90206: Race Condition

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.