CVE-2026-64428

What it actually does

This is a Linux kernel denial-of-service flaw in the SCH GPIO interrupt startup path on PREEMPT_RT kernels. The vulnerable path can call sch_irq_unmask() from irq_startup() during IRQ setup, where execution must not sleep. On PREEMPT_RT, a normal spinlock_t may become a sleeping lock, so taking sch->lock with spin_lock_irqsave() in this non-sleepable context can trigger a kernel lockdep warning and, depending on kernel configuration and runtime behavior, potentially cause instability, task stalls, or a kernel panic. The fix changes the SCH GPIO controller lock to raw_spinlock_t so the IRQ-chip callback uses a non-sleeping lock appropriate for hard IRQ context.

Why it matters to the business

Successful exploitation could disrupt Linux systems that use the affected SCH GPIO driver on real-time kernel configurations, potentially causing service interruption or system crashes. The practical exposure is likely limited to systems with the relevant hardware/driver and PREEMPT_RT behavior, and the currently reported exploitation maturity is none with low EPSS and no CISA KEV listing. However, organizations running real-time Linux in industrial, embedded, telecom, or latency-sensitive environments should prioritize assessment because availability issues on those systems can have outsized operational impact.

How an attack unfolds

An attacker or fault-inducing workload would need the ability to cause the affected SCH GPIO IRQ setup path to execute on a vulnerable PREEMPT_RT Linux kernel. The described trigger path is request_threaded_irq() to __setup_irq() to irq_startup() to sch_irq_unmask() and then sch_irq_mask_unmask(), where the driver takes a regular spinlock that may sleep on PREEMPT_RT. If the condition is reached in invalid context, the kernel may report a sleeping-lock-in-atomic-context error and may degrade, stall, or crash depending on build options, panic-on-warn settings, and system configuration. There is no indication from the supplied data of remote exploitation, public weaponization, ransomware use, or known threat actor exploitation.

How to fix it

Apply a Linux kernel update that includes the SCH GPIO fix converting the controller lock from spinlock_t to raw_spinlock_t. Because no affected product list or exact fixed package versions were provided, track the fix through the Linux kernel stable branches or through the relevant distribution/vendor kernel advisory for CVE-2026-64428. For systems that cannot be immediately patched, reduce exposure by avoiding vulnerable PREEMPT_RT kernel builds where possible, disabling or not loading the affected SCH GPIO driver if not required, restricting local administrative capabilities and kernel module loading, and ensuring panic-on-warn or similar settings are not unnecessarily enabled on production systems where availability is critical.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or source tree contains the SCH GPIO change that uses raw_spinlock_t for the SCH controller lock in the IRQ startup path. Review distribution advisories and kernel changelogs for the CVE or the gpio: sch raw_spinlock_t fix. On source-based builds, inspect the SCH GPIO driver implementation and confirm sch->lock is initialized and used as a raw spinlock where the IRQ mask/unmask path is involved. Operationally, confirm the host is running the updated kernel after reboot, and monitor kernel logs during GPIO/IRQ initialization for absence of sleeping-function-in-invalid-context warnings involving sch_irq_unmask(), sch_irq_mask_unmask(), or __setup_irq().

Typical attack path

1. Identify a Linux system running a vulnerable kernel with PREEMPT_RT behavior and the SCH GPIO driver/hardware path present.
2. Obtain sufficient local capability to load or influence code that requests an IRQ associated with the affected GPIO controller, or otherwise trigger driver/device initialization that requests the IRQ.
3. Trigger IRQ setup so execution follows request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask().
4. Cause the vulnerable path to take a sleeping spinlock in a non-sleepable IRQ startup context.
5. Induce a kernel warning, lockdep splat, stall, or panic, resulting in denial of service where system settings make such conditions fatal.

How to detect it

Look for evidence of prior triggering in kernel logs rather than traditional compromise artifacts. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, panic logs, and monitoring alerts for kernel warnings or unexpected reboots. Search for lockdep or BUG messages indicating a sleeping function was called from invalid context, especially with stack frames involving sch_irq_unmask(), sch_irq_mask_unmask(), irq_startup(), __setup_irq(), request_threaded_irq(), or spin_lock_irqsave() on the SCH GPIO controller lock. Also review uptime/reboot history and watchdog resets around the same timestamps. Because the supplied data indicates no known exploitation, no KEV status, no ransomware use, and no named threat actors, detection should focus on availability symptoms and kernel diagnostic artifacts rather than attacker infrastructure indicators.

• BUG: sleeping function called from invalid context
• hardirqs last disabled at
• __setup_irq.constprop
• sch_rt_spin_lock_irqsave
• sch_irq_mask_unmask
• sch_irq_unmask
• irq_startup
• request_threaded_irq
• spin_lock_irqsave(&sch->lock)
• gpio: sch
• lockdep reported

What your security team should do

• Inventory Linux systems using PREEMPT_RT or real-time kernel variants, especially embedded, industrial, telecom, and latency-sensitive systems.
• Determine whether the SCH GPIO driver/hardware path is present or loaded on those systems.
• Patch affected systems through the applicable Linux distribution or vendor kernel update once available, then reboot into the fixed kernel.
• If patching is delayed, disable the affected driver where operationally safe and restrict kernel module loading and privileged local access.
• Review kernel logs for prior lockdep, BUG, warning, panic, or stall messages matching the affected call path.
• Treat systems with panic-on-warn enabled as higher priority because the bug may turn a warning condition into an immediate outage.
• Continue monitoring vendor advisories because no exact fixed package versions were supplied in the input.