{
  "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"
            },
            {
              "fixed": "6.12.111-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.6-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  net: au1000: move free_irq out of the close-time spinlocked section  au1000_close() calls free_irq() while aup-\u003elock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section.  This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup-\u003elock held across the MAC reset, queue stop and free_irq(dev-\u003eirq, dev).  A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev-\u003eirq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc-\u003erequest_mutex, with au1000_close() and free_irq() on the stack.  Drop aup-\u003elock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.",
  "id": "DEBIAN-CVE-2026-93815",
  "modified": "2026-09-29T10:47:34.481060636Z",
  "published": "2026-09-24T17:17:15.010Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-93815"
    }
  ],
  "upstream": [
    "CVE-2026-93815"
  ]
}