CVE-2026-43357

What it actually does

This vulnerability is a Linux kernel driver reliability flaw in the Industrial I/O gyroscope driver for MPU3050 devices. The driver fails to correctly handle errors from runtime power-management resume operations, which can allow code paths to access hardware that did not successfully resume. It can also leave the device runtime power-management usage count in an inconsistent state when enablement fails. A local user with the ability to interact with the affected IIO device interface may be able to trigger kernel-side error paths that result in device malfunction, hangs, or system instability, causing a denial of service. The issue does not provide confidentiality or integrity impact based on the published assessment, and exploitation requires local access.

Why it matters to the business

Systems using affected Linux kernels with the MPU3050 gyroscope driver enabled may be vulnerable to local denial-of-service conditions that can disrupt device availability or require reboot/recovery. The highest risk is for embedded Linux, mobile, sensor, robotics, industrial, or appliance-style deployments where the affected motion sensor driver is present and local users, applications, containers, or compromised services can access device interfaces. The vulnerability is not known to be exploited in the wild, is not in the CISA KEV catalog, has very low EPSS, and has no reported ransomware use, so urgency is lower than remotely exploitable or actively exploited kernel flaws; however, kernel updates should still be applied during normal patch cycles, especially for devices relying on continuous sensor availability.

How an attack unfolds

An attacker first obtains local code execution or an account on a system running an affected Linux kernel with the MPU3050 Industrial I/O gyroscope driver loaded and the relevant device exposed. The attacker then interacts with the IIO device enablement path, such as through sysfs, character-device interfaces, or an application path that enables buffered sensor capture. By repeatedly triggering runtime power-management resume and pre-enable operations under conditions where the device fails to resume or samplerate configuration fails, the flawed driver may continue as if hardware resume succeeded or may leave runtime power-management state inconsistent. This can lead to kernel driver errors, device unavailability, hangs, or broader system instability. Because the vulnerability is local and denial-of-service oriented, exploitation is most plausible after an attacker has already compromised a service, obtained shell access, abused a local user account, or run untrusted code on an affected device.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or hardware vendor that includes the upstream fix for the MPU3050 driver runtime power-management error handling. No specific fixed package versions were provided in the input, so use vendor advisories and distribution kernel changelogs to identify the first fixed kernel for each platform. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the affected MPU3050 driver if the hardware is not required, restricting local access to IIO device nodes and sysfs controls, limiting untrusted local code execution, and applying least-privilege controls to services or containers that can interact with host device interfaces. Embedded product maintainers should backport the driver change that replaces unsafe pm_runtime_get_sync() handling with pm_runtime_resume_and_get() and ensures pm_runtime_put_autosuspend() is called when preenable fails after samplerate configuration failure.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or firmware build includes the MPU3050 runtime power-management fix from the vendor or upstream stable branch. On Linux hosts, check the running kernel version with `uname -r`, compare it to the distribution's fixed kernel advisory, and confirm the installed kernel package is the active booted kernel after reboot. If source validation is possible, confirm the MPU3050 core driver uses `pm_runtime_resume_and_get()` for resume handling and includes cleanup with `pm_runtime_put_autosuspend()` when `set_8khz_samplerate()` fails in the preenable path. To validate exposure reduction, check whether the affected driver is loaded, whether MPU3050/IIO devices are present, and whether untrusted users or workloads can access `/sys/bus/iio/`, `/dev/iio:*`, or related device nodes. Functional testing should verify that enabling and disabling sensor capture no longer produces kernel warnings, power-management usage-count leaks, or device hangs.

Typical attack path

1. Gain local execution on a Linux system that includes the affected MPU3050 gyroscope driver.
2. Confirm the MPU3050/IIO device is present, enabled, and accessible through local device or sysfs interfaces.
3. Trigger the affected sensor enablement or buffered capture path repeatedly or under conditions that cause runtime power-management resume failure.
4. Cause the driver to access hardware after a failed resume or leave runtime power-management accounting inconsistent.
5. Induce device failure, kernel warnings, system instability, or a denial-of-service condition requiring service restart, driver reload, or reboot.

How to detect it

There are no public reports of active exploitation, no KEV listing, and no known ransomware association for this issue. Detection should focus on local abuse or instability indicators rather than network indicators. Review kernel logs, persistent journal logs, audit logs, and endpoint telemetry for repeated interactions with IIO sensor interfaces followed by kernel warnings, driver errors, runtime power-management failures, device hangs, or reboots. Useful log sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, Linux auditd events for access to `/sys/bus/iio/` or `/dev/iio:*`, EDR process telemetry showing unusual scripts or binaries accessing sensor interfaces, and service manager logs showing unexpected restarts after kernel/device faults. Investigate processes repeatedly writing to IIO buffer enable controls or interacting with MPU3050 sysfs paths shortly before kernel warnings, system instability, watchdog resets, or reboots. Because the flaw is local, correlate suspected activity with account logins, privilege changes, container escapes or misconfigurations, and recent execution of untrusted code.

• mpu3050
• mpu3050-core
• iio: gyro: mpu3050
• pm_runtime_get_sync
• pm_runtime_resume_and_get
• pm_runtime_put_autosuspend
• set_8khz_samplerate
• /sys/bus/iio/devices/
• /dev/iio:device
• in_anglvel
• buffer/enable
• kernel: mpu3050
• kernel: iio
• runtime PM
• failed to resume
• watchdog: BUG: soft lockup
• kernel panic

What your security team should do

• Inventory Linux systems, embedded devices, and appliances that include motion sensors or have the MPU3050/IIO gyroscope driver enabled.
• Prioritize patching for systems where local users, third-party applications, containers, or exposed services can access sensor devices or host device nodes.
• Apply vendor kernel updates that include the upstream MPU3050 runtime power-management fix; reboot systems where required to activate the fixed kernel.
• If the sensor is not needed, disable or blacklist the MPU3050 driver as a compensating control until patched.
• Restrict permissions on IIO device nodes and sysfs interfaces so only trusted services can interact with sensor hardware.
• Review container and sandbox configurations to ensure untrusted workloads are not granted unnecessary access to host `/dev` or `/sys` device interfaces.
• Monitor kernel logs for MPU3050, IIO, runtime power-management, or device resume errors that may indicate attempted triggering or unstable hardware behavior.
• Treat any confirmed denial-of-service event as a local post-compromise signal and investigate how the triggering process obtained access to the device interface.