Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-31761 is a high-severity Race Condition (CWE-362) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 1th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-39 (Process Isolation) and SC-4 (Information in Shared System Resources) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-31761 is a race condition vulnerability in the Linux kernel's Industrial I/O (IIO) subsystem, specifically within the MPU3050 gyroscope driver. The flaw occurs because the iio_device_register() function is invoked too early in the probe function, potentially exposing the device to concurrent access issues before full initialization. It affects Linux kernel versions prior to the application of the referenced stable patches and carries a CVSS v3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
A local attacker with low privileges can exploit this vulnerability through low-complexity means without requiring user interaction. Exploitation involves triggering the race condition during device probing, which could allow the attacker to achieve high impacts on confidentiality, integrity, and availability, potentially leading to arbitrary code execution or system disruption within the context of the affected driver.
Mitigation is provided through kernel patches in multiple stable branches, which relocate iio_device_register() to the end of the probe function and position iio_device_unregister() accordingly to eliminate the race. These fixes are available in the following commits: https://git.kernel.org/stable/c/051ca43b0e0e4b66bfd349cd53ccf231ad1d69b7, https://git.kernel.org/stable/c/22487ef85f6dd9499ddf49b85a08afc50a3f1992, https://git.kernel.org/stable/c/2a4537653d200fda2a8516083459f8ff6194f8fc, https://git.kernel.org/stable/c/4c05799449108fb0e0a6bd30e65fffc71e60db4d, and https://git.kernel.org/stable/c/59a317f8215674c8330817770497301bfb2c1b99. Security practitioners should update to kernels incorporating these changes.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-26574
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe…
more
function and place iio_device_unregister() accordingly.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V10.4.2V10.4.5V15.1.3V15.4.1
Mitigating Controls (NIST 800-53 r5) AI
Maintaining separate execution domains for each process structurally eliminates unintended concurrent access to the same shared resources.
Preventing unintended information transfer through shared system resources directly addresses the improper concurrent modification that defines a race condition.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require proper synchronization primitives and concurrency testing that prevent race conditions.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect race conditions, but does not prevent them at design or coding time.
Secure SDLC mandates concurrency controls and synchronization primitives that directly prevent race conditions.
Application security requirements can specify thread-safety and locking rules, but do not prescribe implementation details.
Secure architecture principles require proper synchronization and resource isolation, addressing the root cause of CWE-362.
Secure coding standards explicitly forbid unsafe concurrent access patterns and mandate atomic operations or locks.