CVE-2026-53226

What it actually does

This is a Linux kernel use-after-free/resource-leak flaw in the Rockchip GPIO driver teardown path. The driver allocates IRQ domain generic chips during probe, but previously did not free those generic chip structures before removing the IRQ domain. As a result, stale generic IRQ chip objects could remain on the kernel-wide generic chip list after the GPIO bank was removed. Later suspend, resume, shutdown, or IRQ-generic-chip callbacks could dereference freed or invalid driver state, potentially causing a kernel oops, panic, or system crash. The practical impact is primarily local denial of service on systems using the affected Rockchip GPIO driver; reliable privilege escalation is not indicated by the available description.

Why it matters to the business

Organizations running Linux on Rockchip-based embedded, IoT, industrial, mobile, or edge devices may experience crashes during device teardown, driver unload, shutdown, or power-management transitions. For operational technology and appliance-like systems, this can translate into service interruption, unexpected reboots, failed upgrades, or degraded availability. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity noted, and has a low EPSS score, so urgency is lower than for remotely exploitable kernel flaws; however, patching is still important for fleets where physical devices, local users, containers with excessive device access, or automated power-management workflows can trigger driver removal or suspend/resume paths.

How an attack unfolds

An attacker would need the ability to influence the affected Rockchip GPIO driver lifecycle or related power-management paths on a vulnerable Linux system. In a realistic scenario, the attacker first gains local access or control over a privileged context capable of unbinding the GPIO platform device, unloading a relevant module if modularized, manipulating sysfs driver binding, or triggering suspend/resume or shutdown sequences after teardown. Because the driver failed to remove generic IRQ chip allocations from the global generic chip list, later kernel IRQ chip callbacks may traverse stale entries and access memory associated with a removed GPIO bank. This can result in a kernel crash or hang. The vulnerability is not described as remotely exploitable over the network and exploitation generally depends on local privileges, device-specific hardware support, and whether the Rockchip GPIO driver is present and active.

How to fix it

Apply a Linux kernel update from the operating system, device, board-support-package, or appliance vendor that includes the Rockchip GPIO fix: explicitly calling irq_domain_remove_generic_chips() before removing the IRQ domain in rockchip_gpio_remove(). If vendor packages are not yet available, backport or cherry-pick the upstream kernel fix into affected Rockchip kernel branches and rebuild/test the kernel or BSP image. As interim mitigations, restrict local shell and administrative access, prevent untrusted workloads from receiving broad device, sysfs, module-management, or power-management permissions, avoid unnecessary driver unbind/unload operations, and disable exposed debug or maintenance interfaces that allow device teardown on production devices.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking the vendor changelog, kernel source, or backported patch history for the Rockchip GPIO teardown change that invokes irq_domain_remove_generic_chips() before irq_domain_remove(). On source-based builds, inspect drivers/gpio/gpio-rockchip.c and verify rockchip_gpio_remove() removes generic chips before removing the IRQ domain. On packaged systems, verify the installed kernel version matches a vendor advisory or release that includes this fix. For functional validation on non-production hardware, exercise safe driver bind/unbind or suspend/resume/shutdown test cycles and confirm there are no kernel oops, panic, KASAN use-after-free reports, or generic IRQ chip warnings related to the Rockchip GPIO driver.

Typical attack path

1. Identify a Linux system running on Rockchip hardware or a kernel build with the Rockchip GPIO driver enabled.
2. Obtain local access or control of a privileged execution context capable of interacting with kernel driver binding, module unload, device teardown, or system power-management operations.
3. Trigger removal or unbinding of the affected Rockchip GPIO bank or otherwise cause the driver teardown path to run.
4. Trigger a later suspend, resume, shutdown, or generic IRQ chip callback path that traverses the stale generic chip list.
5. Cause a kernel oops, panic, reboot, or hang due to dereferencing stale generic IRQ chip state.

How to detect it

Because this flaw primarily causes kernel instability rather than creating a durable attacker artifact, post-exploitation detection should focus on kernel, crash, and device-management telemetry. Review dmesg, journald, kern.log, serial console logs, pstore/ramoops, kdump/vmcore data, watchdog-reset records, and embedded device management logs for kernel oops or panic events involving the Rockchip GPIO driver, IRQ domains, generic IRQ chips, suspend/resume, shutdown, or driver unbind operations. Correlate crash timestamps with local administrative actions, sysfs writes under driver bind/unbind paths, module unload attempts, firmware upgrade workflows, container/device permission changes, or automated power-management events. In environments using auditd or EDR for Linux, look for privileged writes to /sys/bus/platform/drivers/*/unbind, use of rmmod/modprobe against GPIO-related modules, or scripts that trigger suspend/resume around the time of kernel crashes. Absence of these artifacts does not prove non-exploitation, because a panic may interrupt logging before complete evidence is written.

• gpio-rockchip
• rockchip_gpio_remove
• irq_domain_remove_generic_chips
• irq_domain_remove
• irq_alloc_domain_generic_chips
• generic IRQ chip
• genirq
• kernel NULL pointer dereference
• use-after-free
• KASAN: use-after-free
• BUG: unable to handle kernel
• Kernel panic
• Oops:
• /sys/bus/platform/drivers/*/unbind
• /sys/bus/platform/drivers/*/bind
• /sys/power/state
• rmmod gpio-rockchip
• modprobe -r gpio-rockchip

What your security team should do

• Inventory Linux devices and firmware images that run on Rockchip SoCs or include the Rockchip GPIO driver.
• Prioritize patching embedded, edge, industrial, and appliance systems where unplanned reboots have high operational impact.
• Obtain fixed kernels or BSP images from the relevant OS, hardware, or appliance vendor; where necessary, backport the upstream driver fix.
• Restrict local administrative access and remove unnecessary capabilities that allow untrusted users or containers to unload modules, unbind platform devices, write to sensitive sysfs paths, or trigger system power-state transitions.
• Review recent kernel crash, panic, watchdog-reset, and power-management logs on Rockchip-based devices for signs of driver teardown followed by IRQ/generic-chip failures.
• Test patched images on representative hardware with suspend/resume, shutdown, reboot, and upgrade workflows before fleet-wide deployment.