CVE-2026-93815: net: au1000: move free_irq out of the close-time spinlocked section
In the Linux kernel, the following vulnerability has been resolved:
net: au1000: move freeirq out of the close-time spinlocked section
au1000close() calls freeirq() while aup->lock is still held with spinlockirqsave(). freeirq() 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 au1000close() .ndostop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and freeirq(dev->irq, dev).
A directed runtime validation kept that ndostop carrier and the same freeirq(dev->irq, dev) operation under the driver lock. Lockdep reported "BUG: sleeping function called from invalid context" and "Invalid wait context" while freeirq() was taking desc->requestmutex, with au1000close() and freeirq() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In au1000_close(), release aup->lock and move free_irq(dev->irq, dev) outside the close-time spinlocked section; perform IRQ teardown only after leaving the spin_lock_irqsave() context.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel au1000 network driver are exposed when that driver's close/stop path is invoked. The issue is in au1000_close(), the driver's ndo_stop handler.
What event triggers the vulnerable code path?
The problematic path runs during device close or stop, when au1000_close() tears down the device and frees its IRQ. The failure occurs because free_irq() may sleep while the driver spinlock is held.
How can administrators identify whether the issue has occurred?
Lockdep can report "BUG: sleeping function called from invalid context" and "Invalid wait context" with au1000_close() and free_irq() in the stack trace. The reported sleep occurs while free_irq() takes the IRQ descriptor request mutex.
What does the fix change?
The fix releases aup->lock before calling free_irq(). Device and queue shutdown remain protected before IRQ teardown, while the sleepable IRQ cleanup runs outside the spinlocked section.