[PATCH] nvmet: fix max_qid race between configfs and controller allocation

Keith Busch kbusch at kernel.org
Mon Aug 10 07:30:25 PDT 2026


On Mon, Aug 10, 2026 at 03:33:01PM +0200, Maurizio Lombardi wrote:
> 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.

I think there's still a race in nvmet_check_cqid() such that a command
can access an out-of-bounds index if the target side changes
subsys->max_qid to a larger value and the host sends a command with a
larger cqid than the array was initially allocated. Should the max_qid
be copied from the subystem to the controller that allocated the queue
array?



More information about the Linux-nvme mailing list