CVE-2026-31763

What it actually does

This is a local availability flaw in the Linux kernel MPU3050 gyroscope Industrial I/O driver. During driver teardown, the driver calls free_irq() with the wrong device identifier: the IRQ was registered using the trigger object, but teardown attempts to free it using the MPU3050 device object. Because free_irq() matches both the IRQ number and the device identifier, the interrupt handler may not be correctly removed. On affected systems where this driver and hardware path are present, repeated driver removal, device unbinding, or teardown activity can leave IRQ state inconsistent and may trigger kernel warnings, crashes, or denial of service.

Why it matters to the business

The main risk is disruption of affected Linux systems rather than data theft or privilege escalation. Systems using the MPU3050 gyroscope driver, especially embedded, industrial, mobile, sensor, or appliance-style Linux deployments, could experience kernel instability or crashes if a local user or local process can trigger the affected driver teardown path. The CVSS availability impact is high, but exploitation requires local access and low privileges, EPSS is very low, there is no known public exploit maturity, and it is not listed in CISA KEV or known ransomware use, so remediation should be prioritized based on whether the affected driver is present and used in production.

How an attack unfolds

An attacker first needs local access to a Linux system where the MPU3050 gyroscope driver is available and the vulnerable driver path can be exercised. The attacker then triggers driver teardown activity, such as unbinding the device, unloading the module where permitted, or otherwise forcing the affected probe/remove lifecycle. Because the driver frees the IRQ using the wrong object, the IRQ handler may remain registered or kernel IRQ bookkeeping may become inconsistent. Subsequent interrupts or repeated teardown attempts can produce kernel warnings, stale IRQ handling, or a crash, resulting in denial of service. This is not expected to provide remote code execution, data disclosure, or privilege escalation based on the supplied description.

How to fix it

Apply a Linux kernel update from the operating system or device vendor that includes the MPU3050 driver fix changing the teardown free_irq() call to use the same device identifier used when the IRQ was registered. No exact fixed package versions were provided, so track vendor advisories and kernel changelogs for the fix titled around 'iio: gyro: mpu3050: Fix incorrect free_irq() variable.' If immediate patching is not possible and the MPU3050 gyroscope is not required, disable or blacklist the mpu3050 driver/module, remove the hardware/device configuration, or prevent the driver from binding. Limit local access to users who can unload modules, write to sysfs driver bind/unbind interfaces, or otherwise manipulate device lifecycle state. For embedded products, rebuild and redeploy firmware/kernel images containing the upstream fix.

How to confirm the fix worked

Confirm that the running kernel package or firmware build includes the MPU3050 free_irq() fix from the vendor or upstream kernel. On source-based builds, verify the MPU3050 driver teardown path calls free_irq() with the IRQ dev_id matching the object used during request_irq()/request_threaded_irq(), specifically the trigger object rather than the MPU3050 device object. Check whether the driver is present or loaded using module listings, kernel config, device tree/ACPI configuration, and IIO device enumeration. After patching, validate that binding and unbinding the MPU3050 device or unloading the driver in a test environment does not produce 'Trying to free already-free IRQ' warnings, kernel oops messages, or crashes. Confirm the system is booted into the updated kernel rather than only having the package installed.

Typical attack path

1. Obtain local access to a Linux system with the vulnerable MPU3050 gyroscope driver present.
2. Confirm the MPU3050 IIO gyroscope driver or module is loaded or can be loaded.
3. Trigger the device or driver teardown path, such as through driver unbind, device removal, or module unload if permitted.
4. Cause free_irq() to be called with the incorrect device identifier.
5. Repeat teardown or cause interrupts to occur after the failed IRQ cleanup.
6. Induce kernel warnings, IRQ inconsistency, kernel crash, or system denial of service.

How to detect it

Look for signs that the vulnerable driver teardown path was exercised before a crash or reboot. Relevant sources include kernel logs, journald, dmesg output, syslog, audit logs, endpoint telemetry, module load/unload records, and sysfs access monitoring where enabled. Search for mpu3050 driver activity followed by IRQ cleanup warnings, kernel oops messages, panic traces, hung tasks, or unexpected reboot events. Audit for local commands or process activity involving module unloads, modprobe/rmmod, or writes to driver bind/unbind files. Because this issue does not define a network protocol artifact and exploitation is local, network IOCs are not expected. There are no known named threat actors, KEV exploitation, ransomware use, or public exploit maturity in the supplied data, so detection should focus on local kernel and device-management artifacts rather than campaign-specific indicators.

• Trying to free already-free IRQ
• mpu3050
• iio: gyro: mpu3050
• /sys/bus/i2c/drivers/mpu3050/unbind
• /sys/bus/i2c/drivers/mpu3050/bind
• modprobe mpu3050
• rmmod mpu3050
• kernel panic
• BUG: kernel NULL pointer dereference
• Unable to handle kernel
• Oops:
• Call Trace:
• irq
• free_irq

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and sensor platforms for the MPU3050 gyroscope driver or hardware support.
• Prioritize patching systems where the mpu3050 driver is loaded, hardware is present, or local users/processes can manipulate kernel modules or sysfs driver binding.
• Apply vendor kernel or firmware updates that include the MPU3050 IRQ teardown fix; no exact fixed versions were supplied, so rely on vendor advisories and changelogs.
• If the driver is unnecessary, disable or blacklist the mpu3050 module and verify it cannot auto-load.
• Restrict permissions and operational access that allow local users to unload modules, unbind devices, or trigger driver teardown paths.
• Monitor kernel logs for IRQ cleanup warnings, mpu3050-related remove/unbind activity, kernel oopses, and unexpected reboots.
• Treat this as a targeted local denial-of-service risk rather than a broadly exploitable remote compromise, given low EPSS, no KEV listing, and no known exploit maturity in the provided data.