{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003emutex), 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-\u003ezoned is read once to set up the queue limits and once to initialize the zone resources:    CPU0: echo 1 \u003e nullb0/power         CPU1: echo 1 \u003e nullb0/zoned   nullb_device_power_store()     mutex_lock(\u0026lock)     null_add_dev()       if (dev-\u003ezoned) -\u003e false         /* no BLK_FEAT_ZONED */       nullb_device_zoned_store()                                         test_bit(FL_CONFIGURED) -\u003e 0                                         dev-\u003ezoned = true       blk_mq_alloc_disk()         /* queue is not zoned */       if (nullb-\u003edev-\u003ezoned) -\u003e 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-\u003ezoned 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-\u003ezoned test leaves dev-\u003ezoned set while dev-\u003ezones 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(\u0026lock), also initialize the lock statically with DEFINE_MUTEX().",
  "id": "DEBIAN-CVE-2026-90184",
  "modified": "2026-09-18T04:47:36.297640221Z",
  "published": "2026-09-17T17:17:12.833Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-90184"
    }
  ],
  "upstream": [
    "CVE-2026-90184"
  ]
}