CVE-2026-90206

Vulnérabilité non évaluée dans Linux (Linux)

CVSS 0.0 · Non évaluée
EPSS 0.2%
Linux•Linux•Versions : 7.2.6, <=*, 6.18.57, <2c23fc91789dfd9db746edb3ae9b90d65fabd410, <=7.2.*, <=6.18.*, <6e6f8e3bfc66dff1833a48ecfd857268cff3be84, 7.3, 0, 3e980f5995e0bb4d86fef873a9c9ad66721580d0, 6.1, <6.1, <f1a8846e06388113dfdbb89dee005083fa9afdf9

Description

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.

Gravité et risque d'exploitation

CVE-2026-90206 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.21 %, ce qui la place devant 10.1 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions 7.2.6, <=*, 6.18.57, <2c23fc91789dfd9db746edb3ae9b90d65fabd410, <=7.2.*, <=6.18.*, <6e6f8e3bfc66dff1833a48ecfd857268cff3be84, 7.3, 0, 3e980f5995e0bb4d86fef873a9c9ad66721580d0, 6.1, <6.1, <f1a8846e06388113dfdbb89dee005083fa9afdf9) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références