Linux Kernel CVE-2026-64241

Exploitation of the kernel panic vector requires: (1) the gpio-rockchip driver is loaded, meaning the system runs a Rockchip SoC (RK3xxx family) with GPIO interrupt support compiled in; (2) the driver is unbound or the module is removed - an operation requiring root privileges (CAP_SYS_MODULE or equivalent); (3) a GPIO hardware interrupt fires on an active pin after removal completes, a timing condition dependent on external hardware activity. The resource leak vectors (clock and IRQ domain) require only repeated bind/unbind cycles and have no timing dependency, but their impact is limited to gradual resource exhaustion rather than immediate panic. Standard deployments where the gpio-rockchip module remains continuously loaded throughout system uptime are not vulnerable to the panic condition. Non-Rockchip systems are entirely unaffected.

Real-world risk is limited by several converging factors. The CVSS vector AV:L/AC:L/PR:L indicates local access with low privileges, but triggering the worst outcome - a kernel panic from the stale IRQ handler - also requires a hardware interrupt to arrive in the narrow post-unbind window, introducing an implicit timing dependency (AC:L may overstate ease). Driver unbind/removal on production Rockchip systems is not a routine user operation and typically requires elevated privileges, suggesting PR:L in the NVD vector may be optimistic; PR:H is arguably more appropriate for module removal. EPSS of 0.16% at the 5th percentile is consistent with a hardware-specific kernel defect with no known exploitation path. The vulnerability is NOT in CISA KEV, and no POC exists. The 'Information Disclosure' tag in the source data conflicts with the CVSS C:N metric and the description, which describes only availability impact (panic) and resource leaks - this tag discrepancy should be treated as a data artifact. Primary risk is to embedded Rockchip platforms (SBCs, industrial controllers) where repeated driver rebinding occurs, not typical server environments.

An administrator or automated firmware-update script on a Rockchip SBC runs rmmod gpio-rockchip or triggers driver unbind via sysfs. A GPIO line connected to an external hardware peripheral (e.g., a button, sensor, or PMIC) fires an interrupt in the milliseconds after the driver's remove() completes. The kernel's interrupt delivery mechanism invokes the now-stale chained IRQ handler, causing a NULL or wild pointer dereference and a kernel panic, crashing the system. No public exploit exists; the scenario requires hardware-level interrupt coincidence rather than an attacker-controlled trigger.