CVE-2026-31687

What it actually does

This is a local denial-of-service flaw in the Linux kernel OMAP GPIO/MPUIO driver path. The vulnerable code registers the omap_mpuio_driver from inside another driver's probe callback while the device core may already hold a device lock. On affected ARM OMAP-based systems, this can create a driver-core locking deadlock, hang kernel execution paths, or leave stale driver state because the MPUIO driver is not unregistered on module unload. The impact is availability loss only; the provided CVSS vector does not indicate confidentiality or integrity compromise.

Why it matters to the business

Systems that depend on affected Linux kernel builds and OMAP GPIO hardware may become unstable, hang, or require reboot if the vulnerable driver path is triggered. This is most relevant to embedded, industrial, IoT, telecom, or appliance-like Linux deployments using OMAP platforms. Exploitation requires local access with low privileges, EPSS is very low, there is no known CISA KEV listing, and no mature public exploit is indicated, so broad internet-scale exploitation is unlikely; however, the operational impact can still be significant for devices where physical processes, uptime, or remote recoverability matter.

How an attack unfolds

An attacker first needs local access to an affected Linux system, such as a shell, compromised local account, container escape path with sufficient device interaction, or other ability to influence kernel driver/module behavior. The attacker then triggers the OMAP GPIO/MPUIO driver initialization, probing, reprobe, or module load/unload sequence on hardware and kernel builds that include the vulnerable code. Because the driver registration is performed from within another driver's probe callback, the kernel driver core can attempt matching or registration while a device lock is already held. This can produce a deadlock or stuck kernel task, resulting in service disruption, degraded device functionality, or a system hang that may require a reboot or power cycle. There is no indication that this flaw directly enables code execution, privilege escalation, data theft, or ransomware-style activity.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix moving omap_mpuio_driver registration to the module init path and unregistering it during module exit. Because no exact fixed versions were provided, use vendor kernel advisories for the relevant distribution, device vendor, board support package, or long-term-stable kernel branch. Prioritize embedded and appliance deployments using ARM OMAP platforms or kernels with CONFIG_GPIO_OMAP/OMAP MPUIO support. If immediate patching is not possible, reduce local attack surface by limiting shell access, restricting module load/unload capabilities, disabling unnecessary GPIO/MPUIO functionality where operationally safe, enforcing least privilege, and preventing untrusted workloads from accessing host device nodes or kernel module controls.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the vulnerable OMAP GPIO/MPUIO code path and whether the platform actually uses OMAP GPIO hardware. Validate remediation by verifying the installed kernel package or source tree contains the fix that registers omap_mpuio_driver from module init and unregisters it from module exit, rather than from omap_gpio_probe(). On Linux systems, review the running kernel version with uname -a, verify vendor package changelogs/advisories, inspect kernel configuration for OMAP GPIO support, and check whether relevant modules are loaded. After patching, perform controlled regression testing for GPIO functionality, module load/unload behavior, suspend/resume if applicable, and boot-time driver probing to ensure no hung tasks or lock warnings occur.

Typical attack path

1. Obtain local access to an affected Linux system using an account or execution context that can interact with relevant device/module paths.
2. Confirm the system is running an affected kernel build on ARM OMAP-related hardware with the OMAP GPIO/MPUIO driver present or loadable.
3. Trigger GPIO/MPUIO driver probe, reprobe, bind/unbind, or module load/unload behavior.
4. Cause the driver core to register or match drivers while a device lock is already held.
5. Induce a kernel deadlock, hung task, device malfunction, or system-wide availability impact.
6. Force administrators to recover the system through service restart, kernel recovery, reboot, or physical power cycle.

How to detect it

Retrospective detection should focus on availability symptoms rather than classic compromise artifacts. Review kernel logs, persistent journal entries, serial console logs, watchdog logs, crash dumps, and device management telemetry for hangs or resets around GPIO/MPUIO driver activity. Look for kernel lockup, hung task, lockdep, driver probe, module load/unload, or watchdog-reset messages involving OMAP GPIO or MPUIO. Correlate these events with local user logins, sudo activity, module-management commands, sysfs driver bind/unbind writes, container/device passthrough activity, or maintenance scripts. Because this vulnerability is a local DoS and no public exploit maturity or KEV exploitation is indicated, absence of malware artifacts is expected; repeated unexplained OMAP GPIO-related hangs after local access events are the strongest signal.

• omap_gpio_probe
• omap_mpuio_driver
• omap_mpuio_init
• omap_gpio
• gpio-omap
• mpuio
• driver_match_device
• device_lock
• possible circular locking dependency detected
• BUG: sleeping function called from invalid context
• INFO: task hung
• blocked for more than 120 seconds
• watchdog: BUG: soft lockup
• watchdog: hard LOCKUP
• rcu: INFO: rcu_preempt detected stalls
• echo * > /sys/bus/platform/drivers/*/unbind
• echo * > /sys/bus/platform/drivers/*/bind
• modprobe gpio-omap
• rmmod gpio-omap
• insmod gpio-omap

What your security team should do

• Identify Linux assets using ARM OMAP hardware, embedded board support packages, or kernels with OMAP GPIO/MPUIO support enabled.
• Prioritize patching for remotely managed, safety-sensitive, industrial, telecom, appliance, or difficult-to-reboot devices where local denial of service has high operational impact.
• Obtain fixed kernels from the operating system, device, or BSP vendor; if maintaining custom kernels, backport the upstream driver registration/unregistration fix.
• Restrict local interactive access and administrative capabilities on affected devices until patched, especially module loading, device binding/unbinding, and direct access to GPIO-related device nodes.
• Monitor kernel logs for hung tasks, lock dependency warnings, OMAP GPIO/MPUIO probe failures, and unexplained reboots or watchdog resets.
• For containerized or multi-user systems, ensure untrusted workloads cannot access host GPIO devices, sysfs driver bind/unbind controls, or kernel module management interfaces.
• Include this issue in embedded Linux release qualification and regression tests covering driver probe, module unload, suspend/resume, and watchdog recovery behavior.