PT-2026-64650 · Linux · Linux
CVE-2026-64429
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
gpio: eic-sprd: use raw spinlock t in the irq startup path
sprd eic irq unmask() enables the GPIO IRQ and then updates controller
state through sprd eic update(), which takes sprd eic->lock with
spin lock irqsave(). The callback can be reached from irq startup()
while setting up a requested IRQ. That path is not sleepable, but on
PREEMPT RT a regular spinlock t becomes a sleeping lock.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the request threaded irq() -> setup irq() ->
irq startup() -> sprd eic irq unmask() -> sprd eic update() carrier and
used the original spin lock irqsave(&sprd eic->lock) edge. Lockdep
BUG: sleeping function called from invalid context
hardirqs last disabled at ... setup irq.constprop.0 ... [vuln msv]
sprd rt spin lock irqsave+0x1c/0x30 [vuln msv]
sprd eic update.constprop.0+0x48/0x90 [vuln msv]
sprd eic irq unmask.constprop.0+0x35/0x50 [vuln msv]
setup irq.constprop.0+0xd/0x30 [vuln msv]
Convert the Spreadtrum EIC controller lock to raw spinlock t. The
locked section only serializes MMIO register updates and does not contain
sleepable operations, so keeping it non-sleeping is appropriate for the
irqchip callbacks.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux