CVE Catalog

CVE-2026-93815

Low risk· EPSS 5%
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.17%

5th percentile - higher than 5% of all known CVEs

Summary

In the Linux kernel, the au1000 network driver calls free_irq() in au1000_close() while holding aup->lock with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it must not be called inside the spinlocked section.

Risk Assessment

Calling a sleeping function in atomic context triggers lockdep warnings and may lead to system instability or hangs.

Recommendation

Update the Linux kernel to a version containing the fix that drops aup->lock before calling free_irq().

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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->lock 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->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, 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->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock 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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS