CVE-2026-31687: Linux Kernel GPIO OMAP DOS Vulnerability

CVE-2026-31687 Overview

CVE-2026-31687 is a locking vulnerability in the Linux kernel's gpio-omap driver. The flaw stems from omap_gpio_probe() invoking omap_mpuio_init(), which in turn registers the omap_mpuio_driver while a device lock is already held. Commit dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()") exposed a potential deadlock condition caused by this nested driver registration pattern. The issue is classified under [CWE-667] (Improper Locking) and affects local Linux systems running on OMAP-based ARM platforms.

Critical Impact
A local low-privileged user on an affected OMAP-based system can trigger a deadlock condition leading to denial of service through resource unavailability.

Affected Products

Linux Kernel (multiple stable branches prior to fix commits)
Linux Kernel 6.19 release candidates rc1 through rc7
Systems using the gpio-omap driver on OMAP-family ARM SoCs

Discovery Timeline

2026-04-27 - CVE-2026-31687 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-31687

Vulnerability Analysis

The vulnerability resides in the Linux kernel's GPIO subsystem, specifically within the OMAP GPIO driver located in drivers/gpio/gpio-omap.c. The driver's omap_gpio_probe() function calls omap_mpuio_init(), which then attempts to register a separate platform driver (omap_mpuio_driver) with the driver core.

Registering a driver from inside the probe callback of another driver violates the driver core's locking contract. The probe path already holds a device lock, and the subsequent driver registration attempts to acquire locks that conflict with the held device lock. This nested locking sequence creates a potential deadlock.

The enforcement commit dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()") made the locking requirement explicit. Once that enforcement landed, the latent deadlock condition in gpio-omap became reachable on affected systems. Additionally, omap_mpuio_driver was never unregistered, leaking driver core state when the module unloaded.

Root Cause

The root cause is improper locking caused by registering a platform driver from within another driver's probe() callback. The driver core requires that driver_match_device() be called with the device lock held, but registering a new driver triggers a matching loop that conflicts with the already-held lock, producing the deadlock condition described under [CWE-667].

Attack Vector

Exploitation requires local access with low privileges on an OMAP-based Linux system. The attack vector is local because triggering the affected code path requires interaction with the platform device subsystem during driver binding events. Successful exploitation results in a deadlock that exhausts kernel resources and renders the system unresponsive. Confidentiality and integrity are not impacted; the impact is limited to availability.

No public proof-of-concept is available, and the issue is not listed in the CISA Known Exploited Vulnerabilities catalog. The fix moves omap_mpuio_driver registration into the module init call and adds matching unregistration in module_exit().

Detection Methods for CVE-2026-31687

Indicators of Compromise

Kernel soft-lockup or hung-task warnings referencing omap_gpio_probe or omap_mpuio_init in dmesg and /var/log/kern.log.
Stalled platform device binding events on OMAP hardware, observable through udevadm monitor or /sys/bus/platform/drivers/.
Unresponsive GPIO subsystem after module load or device hotplug on affected kernels.

Detection Strategies

Inventory running kernel versions across Linux fleets and flag hosts running unpatched 6.19-rc builds or earlier vulnerable stable branches.
Monitor kernel ring buffer output for lockdep warnings and INFO: task ... blocked messages tied to GPIO probe paths.
Correlate platform driver registration failures with system availability degradation on ARM/OMAP devices.

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM platform and alert on hung-task and deadlock signatures.
Track kernel package versions through configuration management and reconcile against the fixed commits referenced in the kernel.org advisories.
Baseline normal GPIO driver bind/unbind behavior to detect anomalous stalls during boot or module operations.

How to Mitigate CVE-2026-31687

Immediate Actions Required

Apply the upstream kernel patches that move omap_mpuio_driver registration out of the probe callback and into the module initcall.
Identify all OMAP-based ARM systems in the environment and prioritize patching for those workloads.
Restrict local access on affected hosts until the patched kernel is deployed, since exploitation requires local privileges.

Patch Information

Workarounds

Disable the gpio-omap module on systems that do not require OMAP GPIO functionality by blacklisting it in /etc/modprobe.d/.
Limit local shell access and enforce least-privilege controls to reduce the population of users able to trigger the affected code paths.
Schedule reboots into patched kernels promptly, since the deadlock requires kernel-level remediation and cannot be fully mitigated in userspace.

bash

# Configuration example: verify kernel version and blacklist module pending patch
uname -r
echo "blacklist gpio-omap" | sudo tee /etc/modprobe.d/blacklist-gpio-omap.conf
sudo update-initramfs -u