CVE-2026-31732

What it actually does

This is a Linux kernel availability flaw in the GPIO subsystem. An error path in gpiochip_add_data_with_key() can fail to drop a device reference after device_initialize() has transferred cleanup responsibility to the GPIO device release path. When GPIO chip registration fails after that point, kernel objects and associated resources can be leaked instead of released. Repeatedly triggering the affected error path can consume kernel memory or device references, potentially degrading the system or causing a denial of service. The CVSS vector indicates local access with low privileges, no user interaction, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, especially systems that rely on GPIO-capable hardware, embedded platforms, industrial devices, appliances, or hosts where local users or workloads can influence driver/device registration. The issue is not currently listed in CISA KEV, is not reported as used in ransomware campaigns, has very low EPSS probability, and has no public exploit maturity indicated, so broad opportunistic exploitation is unlikely; however, availability-sensitive systems should still treat kernel DoS flaws as operational risk because exploitation can interrupt services and may require reboot or maintenance intervention.

How an attack unfolds

An attacker first obtains local execution on an affected Linux system with sufficient ability to exercise GPIO-related device or driver registration paths, such as through permitted module/device interactions, hardware hotplug paths, namespace/container-adjacent device exposure, or other locally reachable kernel interfaces that cause GPIO chip registration attempts. The attacker then repeatedly triggers conditions that make gpiochip_add_data_with_key() fail after device_initialize() has run but before registration completes. On vulnerable kernels, the failing path does not correctly drop the reference to the GPIO device object, so each failed attempt can leak kernel resources. By repeating the operation, the attacker can gradually exhaust kernel memory or related object references until the host becomes degraded, unresponsive, or crashes. There is no indication from the supplied data that this enables code execution or data theft.

How to fix it

Update to a Linux kernel version that includes the upstream GPIO fix for gpiochip_add_data_with_key() resource cleanup. Because no exact fixed package versions were provided, use the fixed kernel supplied by the operating system or distribution vendor and verify that the patch titled "gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()" or an equivalent backport is present. For source-built kernels, apply the upstream stable patch and rebuild/redeploy the kernel. If immediate patching is not possible, reduce exposure by restricting local shell access, limiting the ability to load kernel modules or bind/unbind devices, disabling unneeded GPIO drivers/interfaces, enforcing module-loading controls such as module signing and lockdown where applicable, and isolating untrusted workloads from host device nodes and privileged container capabilities. Reboot into the fixed kernel after installation; installing kernel packages alone is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is fixed. Check the active kernel with uname -r and compare it to the distribution advisory or vendor package version that contains the GPIO resource-leak fix. For source-based builds, inspect the kernel source or build metadata to verify the gpiochip_add_data_with_key() error path calls the appropriate GPIO device put/release logic after device_initialize() failures and avoids the stale reference leak. Validate that systems have rebooted into the updated kernel. Where practical, review kernel logs after update for recurring GPIO chip registration failures and confirm memory usage remains stable under normal GPIO/device initialization activity.

Typical attack path

1. Gain local code execution or an authenticated low-privileged foothold on an affected Linux system.
2. Identify an accessible path that can cause GPIO chip/device registration attempts, such as a driver, device, hotplug, or exposed GPIO-related interface.
3. Force registration to fail after GPIO device initialization but before successful chip registration.
4. Repeat the failing registration path to leak kernel references/resources.
5. Continue until kernel memory pressure, device-management failure, service degradation, hang, or crash occurs.

How to detect it

Look for evidence of local activity that repeatedly exercises GPIO or device-registration paths followed by kernel memory pressure or instability. Useful log sources include kernel ring buffer output, system journal kernel facility logs, /var/log/kern.log, /var/log/messages, audit logs for module loading and device bind/unbind operations, container runtime logs for privileged device access, and EDR telemetry for local processes invoking modprobe, insmod, rmmod, udevadm, or sysfs device binding controls. Indicators of possible exploitation include recurring GPIO chip registration failures, repeated driver probe failures, increasing slab/kernel memory usage without recovery, OOM killer activity, soft lockups, hung tasks, kernel warnings or stack traces involving gpiolib/gpiochip_add_data_with_key(), and availability events requiring reboot. Because this is a resource-leak DoS rather than a payload-dropping vulnerability, durable file/network IOCs are unlikely; detection should focus on behavioral correlation between repeated local device-registration failures and resource exhaustion.

• gpiochip_add_data_with_key
• gpiodev_release
• gpio_device_put
• gpiochip
• gpiolib
• /dev/gpiochip
• /sys/bus/platform/drivers
• /sys/bus/platform/drivers/*/bind
• /sys/bus/platform/drivers/*/unbind
• modprobe
• insmod
• rmmod
• udevadm trigger
• Out of memory
• oom-killer
• Kernel panic
• soft lockup
• hung task

What your security team should do

• Prioritize patching on Linux systems with GPIO hardware, embedded/edge devices, industrial appliances, kiosk/IoT platforms, and systems that allow local users, containers, or automation to interact with devices or kernel modules.
• Track vendor advisories for the exact fixed kernel package because no fixed versions were supplied in the input, and ensure systems reboot into the remediated kernel.
• Restrict local privilege surfaces that can reach kernel device registration paths: module loading, device bind/unbind operations, privileged containers, direct /dev access, and unnecessary GPIO interfaces.
• Enable kernel hardening controls where supported, including module signing, kernel lockdown, least-privilege device cgroups, and denial of untrusted privileged containers.
• Monitor for unexplained kernel memory growth, repeated GPIO/device registration errors, OOM events, soft lockups, or crashes on affected systems.
• Treat the issue as lower internet-scale urgency due to low EPSS, no KEV listing, and no known exploit maturity, but do not defer on availability-critical or physically exposed Linux deployments.