CVE-2026-31762

What it actually does

This is a local Linux kernel denial-of-service flaw in the IIO MPU3050 gyroscope driver. During device probe, the driver requests a threaded IRQ handler and then attempts to register an IIO trigger. If trigger registration fails, the error path returns without freeing the IRQ handler, leaving an interrupt resource allocated. Repeatedly exercising this failure path can leak kernel IRQ resources and may eventually cause driver malfunction, device initialization failure, broader kernel instability, or loss of availability. The issue does not provide confidentiality or integrity impact by itself and requires local access with enough privilege or system control to influence device probing, module loading, driver binding, or related hardware/driver state.

Why it matters to the business

Affected Linux systems that include and use the MPU3050 gyroscope driver may be susceptible to local availability disruption. In practice, this is most relevant to embedded, industrial, mobile, IoT, robotics, or sensor-enabled Linux deployments where gyroscope hardware and IIO drivers are enabled. The CVSS score is medium, EPSS is very low and flat, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad opportunistic exploitation is unlikely; however, organizations with safety-sensitive or uptime-sensitive Linux sensor platforms should still prioritize normal kernel maintenance because repeated local triggering could degrade system reliability.

How an attack unfolds

An attacker first needs local access to a Linux system where the MPU3050 IIO gyroscope driver is present and can be exercised. The attacker then causes the driver probe path to run, for example through device binding, module loading, or repeated device initialization activity, while also causing or relying on a condition where iio_trigger_register() fails after request_threaded_irq() has already succeeded. Because the vulnerable error path does not release the IRQ handler, each failed probe can leave resources behind. By repeating the sequence, the attacker may exhaust IRQ-related kernel resources or create inconsistent driver state, resulting in denial of service, device failure, or kernel instability. This is not a remote code execution issue and there is no indication of ransomware use, KEV exploitation, or named threat actor activity for this vulnerability.

How to fix it

Apply a Linux kernel update that includes the MPU3050 driver fix for the missing IRQ cleanup path in drivers/iio/gyro/mpu3050-core.c. If distribution-specific fixed versions are not available, track the relevant vendor kernel advisories and update to the first kernel package that backports the fix. As a mitigation, disable or unload the mpu3050 driver where the hardware is not required, remove it from custom kernel builds, blacklist the module if built as loadable, and restrict local administrative capabilities that allow module loading, driver binding/unbinding, or device-tree/ACPI manipulation. On embedded platforms, ship a kernel image with the corrected cleanup goto/error path and validate device probing under failure conditions before deployment.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the MPU3050 IIO gyroscope driver and whether the deployed kernel source or vendor changelog contains the fix that frees the IRQ when iio_trigger_register() fails in mpu3050_trigger_probe(). On running systems, check for a loaded mpu3050 module or built-in driver support, then compare the kernel package version against the Linux distribution or device vendor advisory. Validate the fix in a test environment by forcing the trigger-registration failure path and confirming that the requested IRQ is released on probe failure, with no growth in allocated IRQ handlers after repeated probe attempts. Also verify that module blacklisting or kernel configuration changes are effective on systems where the driver is not needed.

Typical attack path

1. Gain local access to an affected Linux system with the MPU3050 gyroscope driver available or loaded.
2. Identify whether the mpu3050 IIO driver can be bound, unbound, loaded, or otherwise forced through its probe path.
3. Trigger device initialization while causing iio_trigger_register() to fail after the driver has requested a threaded IRQ.
4. Repeat the failed probe path so the IRQ handler is leaked multiple times.
5. Cause resource exhaustion, driver malfunction, or kernel instability that results in local denial of service.

How to detect it

Look for evidence of repeated MPU3050 driver initialization failures, unusual driver bind/unbind activity, module load/unload loops, or IRQ allocation errors. Useful sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, auditd records for writes to sysfs driver bind/unbind files, Linux module load telemetry, EDR process execution events, and embedded device management logs. Focus on sequences where mpu3050-related probe errors occur repeatedly, particularly alongside iio_trigger_register failures, request_threaded_irq activity, IRQ warnings, or commands such as modprobe, rmmod, insmod, or writes to /sys/bus/*/drivers/*/bind and unbind. Because this vulnerability leaves a resource leak rather than a distinctive payload artifact, absence of a single IOC does not rule out exploitation; detection should be behavioral and centered on repeated local triggering of the driver error path and subsequent availability degradation.

• mpu3050
• mpu3050_trigger_probe
• iio_trigger_register
• request_threaded_irq
• drivers/iio/gyro/mpu3050-core.c
• /sys/bus/i2c/drivers/mpu3050/bind
• /sys/bus/i2c/drivers/mpu3050/unbind
• modprobe mpu3050
• rmmod mpu3050
• insmod mpu3050
• genirq: Flags mismatch irq
• request_irq
• failed to request irq
• failed to register trigger

What your security team should do

• Inventory Linux systems, especially embedded and sensor-enabled platforms, for use of the MPU3050 IIO gyroscope driver.
• Prioritize kernel updates through normal patch cycles; accelerate remediation for safety-critical, uptime-critical, or remotely managed embedded devices where local users can influence driver binding or module loading.
• If the hardware is not used, disable the mpu3050 driver by kernel configuration, module blacklist, or removal from the deployed image.
• Restrict local privileges that allow loading/unloading kernel modules, binding/unbinding devices, or modifying hardware description interfaces.
• Monitor kernel logs for repeated mpu3050 probe failures, IRQ allocation anomalies, or repeated driver bind/unbind activity.
• For product teams maintaining custom kernels, cherry-pick the upstream fix and add regression tests for failed probe cleanup paths.