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

CVE-2026-31687 Overview

A vulnerability has been identified in the Linux kernel's GPIO OMAP driver where the omap_mpuio_driver is improperly registered from within the omap_gpio_probe() callback function. This design flaw violates driver core constraints and can lead to a potential deadlock condition when a device lock is already held during driver registration.

The issue was introduced by commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") which registered the omap_mpuio_driver from omap_mpuio_init(), called during the probe sequence. This architectural violation was exposed by commit dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()"), which enforces device lock requirements during driver matching operations.

Critical Impact

Systems running affected Linux kernel versions with OMAP GPIO hardware may experience deadlock conditions during driver initialization, potentially causing system hangs or denial of service on ARM-based embedded devices.

Affected Products

• Linux Kernel (OMAP GPIO subsystem)
• ARM-based systems using OMAP chipsets
• Embedded devices with OMAP MPUIO functionality

Discovery Timeline

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

Technical Details for CVE-2026-31687

Vulnerability Analysis

This vulnerability represents a race condition and deadlock issue within the Linux kernel's GPIO OMAP driver subsystem. The core problem stems from an improper driver registration pattern where omap_mpuio_driver is registered from within another driver's probe() callback function.

The Linux driver core model explicitly prohibits registering drivers when a device lock is already held. When omap_gpio_probe() executes, it calls omap_mpuio_init(), which attempts to register the MPUIO driver. Since the probe function is called with device locks held, this nested registration can trigger a deadlock scenario where the system waits indefinitely for lock acquisition.

Additionally, the vulnerability includes a resource management flaw: the omap_mpuio_driver is never properly unregistered from the driver core, even when the module is unloaded. This can lead to stale driver references and potential use-after-free conditions in certain edge cases.

Root Cause

The root cause is an architectural violation in the OMAP GPIO driver design. The original implementation in commit 11a78b794496 placed driver registration logic inside the omap_mpuio_init() function, which is invoked during the probe sequence of the parent GPIO driver. This approach conflicts with the kernel's driver core locking semantics that were later enforced by commit dc23806a7c47.

The proper pattern for driver registration is to perform it during module initialization (module_init()) rather than during device probing, ensuring no device locks are held during the registration process.

Attack Vector

While this vulnerability has an unknown attack vector classification, the potential exploitation scenarios include:

Local attackers with kernel module loading privileges could potentially trigger the deadlock condition by forcing module reload sequences. The vulnerability primarily affects system availability rather than confidentiality or integrity, as the deadlock results in denial of service rather than code execution.

The fix relocates the omap_mpuio_driver registration to the module's initcall function and adds proper cleanup in module_exit(), ensuring proper lifecycle management and avoiding the deadlock-prone registration pattern.

Detection Methods for CVE-2026-31687

Indicators of Compromise

• System hangs or freezes during OMAP GPIO driver initialization
• Kernel lockup warnings in dmesg referencing GPIO or MPUIO driver functions
• Deadlock detector messages involving omap_gpio_probe or omap_mpuio_init call chains

Detection Strategies

• Monitor kernel logs for lockdep warnings related to GPIO driver initialization
• Implement kernel debugging with CONFIG_PROVE_LOCKING enabled to detect lock ordering violations
• Use SentinelOne's kernel-level monitoring to detect anomalous driver behavior patterns

Monitoring Recommendations

• Enable kernel lockdep debugging on development and test systems running OMAP hardware
• Configure alerting for system hangs or watchdog timeouts on embedded ARM devices
• Review kernel logs after module loading operations for any deadlock-related warnings

How to Mitigate CVE-2026-31687

Immediate Actions Required

• Update to a patched Linux kernel version containing the fix commits
• Avoid loading or unloading the OMAP GPIO module on production systems until patched
• Monitor affected systems for signs of deadlock during boot or module operations

Patch Information

The vulnerability has been resolved through multiple kernel git commits that relocate driver registration from the probe callback to the proper module initialization path. The fix ensures:

1. Driver registration occurs during module_init() instead of probe()
2. Proper driver unregistration is performed during module_exit()
3. No device locks are held during driver registration operations

Patches are available across multiple kernel stable branches:

• Kernel Git Commit 03db4dc
• Kernel Git Commit 1c04c3a
• Kernel Git Commit 2211d77
• Kernel Git Commit 32f08c3
• Kernel Git Commit 53a7642

Workarounds

• If kernel updates cannot be applied immediately, avoid dynamic loading/unloading of the OMAP GPIO module
• Consider blacklisting the gpio-omap module if MPUIO functionality is not required
• For embedded systems, build the GPIO driver statically rather than as a module to reduce exposure during module lifecycle events

# Blacklist the module if not required
echo "blacklist gpio-omap" >> /etc/modprobe.d/blacklist-gpio-omap.conf

# Verify the module is not loaded
lsmod | grep gpio_omap