CVE-2026-90184

Description

In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute updates with device setup The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used. null_add_dev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources: CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones() blk_revalidate_disk_zones() is then called for a queue that does not have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the device setup with -EIO: WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560 Clearing dev->zoned in the same window is worse: the queue is created with BLK_FEAT_ZONED but the zone resources are never initialized, so add_disk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which null_process_zoned_cmd() dereferences on the first write. Fix this by taking the global lock, which nullb_device_power_store() already holds across null_add_dev() and null_del_dev(), around both the NULLB_DEV_FL_CONFIGURED test and the update of the device configuration. The submit_queues and poll_queues apply callbacks are now called with that lock held, so remove the locking they did themselves. Since the store methods can run as soon as configfs_register_subsystem() returns, that is, before null_init() gets to mutex_init(&lock), also initialize the lock statically with DEFINE_MUTEX().

Gravité et risque d'exploitation

CVE-2026-90184 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 9.9 % des CVE référencées.

Que faire ?

• Vérifiez si Linux (versions <=6.1.*, <=6.12.*, 0, 6.1.188, <7de792b4c48fba02a36a8077032f7d5093c925e5, 6.18.52, <32456a85995579e56c60cc53c357cda75a9d4f7c, <=6.6.*, <6352e7ead2d8111802a554eeb94886f5a9894bb9, 6.6.157, <4e1f23f9c33c156be7e313b40695af5a3a834739, 7.2.6, <=6.18.*, 6.12.110, <=7.2.*, 3bf2bd20734e3e6ffda53719a9c10fb3ee9c5ffa, <aed8af338a09a64d63b068a803c4ecfc5701dd4c, <=*, <4.14, <d3d35dd045a35991bf6fd13de5f293e6dd7bf3b3, 4.14, 7.3) 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

• https://git.kernel.org/stable/c/6352e7ead2d8111802a554eeb94886f5a9894bb9
• https://git.kernel.org/stable/c/7de792b4c48fba02a36a8077032f7d5093c925e5
• https://git.kernel.org/stable/c/aed8af338a09a64d63b068a803c4ecfc5701dd4c
• https://git.kernel.org/stable/c/32456a85995579e56c60cc53c357cda75a9d4f7c
• https://git.kernel.org/stable/c/d3d35dd045a35991bf6fd13de5f293e6dd7bf3b3
• https://git.kernel.org/stable/c/4e1f23f9c33c156be7e313b40695af5a3a834739