CVE-2026-64428In the Linux kernel, the following vulnerability has been resolved: gpio: sch: use raw_spinlock_t in the irq startup path sch_irq_unmask() enables the GPIO IRQ and then updates the controller state t…
Updated under an hour ago ()
Does this affect you?
It affects linux_kernel. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: gpio: sch: use raw_spinlock_t in the irq startup path sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->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() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.
- CVSS
- 5.5 MEDIUM (v3.1, NVD)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Not given
- NVD analysis
- Analyzed
- Record last updated
- Sep 4, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
linux linux_kernel linux:linux_kernel | from 5.13 before 5.15.212; from 5.16 before 6.1.178; from 6.2 before 6.6.145; from 6.7 before 6.12.97; from 6.13 before 6.18.39; from 6.19 before 7.1.4 | NVD |
References
- https://git.kernel.org/stable/c/286533cb14a3c8a8bd39ff64ea2fc8e1aa0f638bpatch
- https://git.kernel.org/stable/c/3b1aa05ec27eeccc889ecaa3f2d9baa9f453e50dpatch
- https://git.kernel.org/stable/c/41cad91a09d69e8fff4e936db29b1054b4e9f9f7patch
- https://git.kernel.org/stable/c/4508366ab7dd0c2917a51a9c2e23cc1b9d35157apatch
- https://git.kernel.org/stable/c/4f03a15cc73c83740fc355ee22b336492d17b4dapatch
- https://git.kernel.org/stable/c/7a550256d68bbdfa0903ab1c4595c04a6815493apatch
- https://git.kernel.org/stable/c/a235cec779bb39ec8f961a935b28a2ce278c6c64patch
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.