{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  blk-cgroup: save IRQ state in blkg_tryget_closest()  bio_set_dev() associates the bio with a blkg through bio_associate_blkg(). If the blkg lookup misses, blkg_tryget_closest() takes q-\u003equeue_lock with spin_lock_irq() and releases it with spin_unlock_irq(), which unconditionally enables local interrupts.  Callers may call bio_set_dev() with interrupts already disabled, e.g. dm-thin's pool_map() does so while holding pool-\u003elock taken with spin_lock_irq().  The nested spin_unlock_irq() then enables interrupts while pool-\u003elock is still held, so an I/O completion softirq can run on the same CPU, re-acquire pool-\u003elock (thin_endio(), or overwrite_endio() -\u003e complete_mapping_preparation()) and deadlock.  lockdep reports this as inconsistent SOFTIRQ-ON-W to IN-SOFTIRQ-W usage.  Commit 3a762de55b4e (\"block: save irq state in blkg_lookup_create()\") fixed the same problem while the lock lived in blkg_lookup_create(), but commit 9327a865e395 (\"blk-cgroup: don't nest queue_lock under rcu in blkg_lookup_create()\") moved the locking into blkg_tryget_closest() and reverted it to spin_lock_irq().  Save and restore the caller's IRQ state instead.",
  "id": "DEBIAN-CVE-2026-98832",
  "modified": "2026-10-19T04:47:27.135658860Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98832"
    }
  ],
  "upstream": [
    "CVE-2026-98832"
  ]
}