CVE-2026-90206

In the Linux kernel, the following vulnerability has been resolved:

nvmet: fix max_qid race between configfs and controller allocation

The function nvmet_subsys_attr_qid_max_store() can race against

nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified.

Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes:

ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1);

and at this exact point, a userspace process changes max_qid to 128,

nvmet_subsys_attr_qid_max_store() will set the new max_qid 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.

nvmet_alloc_ctrl() then proceeds and adds the new controller to the

subsys->ctrls list. Later, when nvmet_install_queue() is called, it

will see max_qid 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

nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because

nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem)

to modify the attribute, this safely prevents the configfs writer from

modifying max_qid during controller creation.

Copy the max_qid from the subsystem to the controller's structure

during the allocation; ctrl->max_qid never changes as long as the

controller remains in LIVE state, so this will prevent similar race

conditions.