Linux Kernel EUVD-2026-39317

Exploitation requires: (1) the target system must be running on Rockchip SoC hardware with the gpio-rockchip driver loaded; (2) the attacker must have a local low-privilege account (PR:L per CVSS); (3) the gpio-rockchip driver must undergo removal or unbind after boot - this occurs during explicit module unload, sysfs driver unbind, or potentially during device hotplug events; (4) the kernel's IRQ suspend, resume, or shutdown callbacks must subsequently execute and traverse gc_list while the freed chips are still referenced. Exploitation is NOT possible remotely, does not affect systems without Rockchip GPIO hardware, and does not trigger during normal steady-state operation - only on the remove path followed by an IRQ framework callback. Confidentiality and integrity are unaffected; impact is limited to kernel denial-of-service.

The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H scores 5.5 (Medium), accurately reflecting that exploitation requires local authenticated access and produces only availability impact. EPSS at 0.17% (7th percentile) corroborates very low exploitation likelihood - this is a niche driver flaw, not a broadly weaponizable issue. There is no CISA KEV listing and no reported public proof-of-concept. Real-world risk is further constrained by hardware dependency: the vulnerability exists only on systems running Rockchip SoCs (e.g., Raspberry Pi derivatives, Radxa, Orange Pi, and similar ARM SBCs), narrowing the affected population substantially. The use-after-free path requires the GPIO driver to be removed after allocation, which is most plausible during hotplug, module unloading, or power management transitions - scenarios that require either physical access or a local low-privilege account. Signals are consistent: this is a genuine but low-priority kernel stability fix relevant primarily to embedded Linux maintainers targeting Rockchip hardware.

A local user with standard account privileges on a Rockchip SoC device (e.g., a shared embedded Linux system) triggers gpio-rockchip driver removal - via sysfs unbind, module unload, or power management - causing generic chip structures to remain on gc_list. When the kernel subsequently invokes IRQ suspend or resume callbacks (e.g., during system sleep or another device suspend cycle), it dereferences the freed chip memory, producing a use-after-free and kernel panic that crashes the system. No public exploit code exists for this scenario.