--- cve: "CVE-2026-64428" severity: "LOW" cvss: 3.1 epss: "17%" vendor: "Linux" kev: false exploited: false published: "2026-07-25 10:17:26" tags: [cve, security, low] source: tsecurity.de CVE-Dossier exported: "2026-09-05T15:06:18+02:00" --- # CVE-2026-64428 > 3.1 LOW ## Beschreibung 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. ## Patch verfügbar (OSV) - Kernel ≥ 5.15.212 - Kernel ≥ 6.1.178 - Kernel ≥ 6.6.145 - Kernel ≥ 6.12.97 - Kernel ≥ 6.18.39 - Kernel ≥ 7.1.4 ## Referenzen - - - - - - - --- _Exportiert aus dem [tsecurity.de CVE-Dossier](https://tsecurity.de/cve?cve=CVE-2026-64428) · Datenquellen: EUVD (ENISA), NVD, OSV, CISA KEV, FIRST EPSS, Exploit-DB, BSI BITS_