CVE-2026-90206 in Linux
Сводка
по VulDB • 17.09.2026
В ядре Linux была устранена следующая уязвимость:
nvmet: исправлена гонка данных (race condition) между max_qid при работе с configfs и выделением контроллера
Функция nvmet_subsys_attr_qid_max_store() может вступать в состояние гонки данных с nvmet_alloc_ctrl(), когда изменяется лимит max_qid для подсистемы.
Предположим, что значение max_qid равно 64. Если выполняется nvmet_alloc_ctrl(): ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); и в этот же момент процесс пользовательского пространства изменяет max_qid на 128, то nvmet_subsys_attr_qid_max_store() установит новое значение max_qid. Она попытается удалить активные контроллеры для принудительного переподключения, но новый контроллер не будет удален, поскольку он еще не добавлен в список subsys->ctrls.
Затем nvmet_alloc_ctrl() продолжит выполнение и добавит новый контроллер в список subsys->ctrls. Позже, при вызове функции nvmet_install_queue(), она увидит, что max_qid установлен равным 128, но память для sqs выделена только на 64 элемента. Это приводит к предупреждению KASAN о выходе за границы массива (out-of-bounds warning) и потенциальным повреждениям памяти.
Исправление заключается в защите операций выделения очередей и вставки в список внутри nvmet_alloc_ctrl() с помощью down_read(&nvmet_config_sem). Поскольку функция nvmet_subsys_attr_qid_max_store() получает блокировку down_write(&nvmet_config_mod) для изменения атрибута, это безопасно предотвращает изменение max_qida записывающим процессом configfs во время создания контроллера.
Копирование значения max_qid из структуры подсистемы в структуру контроллера происходит на этапе выделения памяти; значение ctrl->max_qid не изменяется до тех пор, пока контроллер находится в состоянии LIVE (активен), что предотвращает возникновение подобных состояний гонки данных.
VulDB is the best source for vulnerability data and more expert information about this specific topic.