EUVD-2026-93156
GHSA-h7gx-m7h9-c46w
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLocal unprivileged process on EyeQ/I6500 host
-
DeliveryHammer anonymous pipe with concurrent read/write
-
ExploitWin LL/SC reordering race in cmpxchg
-
ExecutionCorrupt pipe mutex/kernel state
-
ImpactNULL-deref kernel panic or memory corruption
Vulnerability Assessment
| Exploitation Conditions | Requires the kernel to be built with CONFIG_EYEQ and running on MIPS I6500 CPU cores (e.g. Mobileye EyeQ5 SoC), where lld/scd provide no ordering guarantees - the fix selects CONFIG_WEAK_REORDERING_BEYOND_LLSC to inject sync instructions around LL/SC loops. Exploitation needs LOCAL access as an authenticated user (PR:L) able to run syscalls that stress a kernel cmpxchg-protected lock (the reproducer uses tightly contended anonymous-pipe read/write loops). LIMITING FACTORS: no network vector, no effect on x86/ARM or non-EyeQ MIPS configs, success depends on winning a CPU-reordering race window, and the observed outcome is a kernel oops rather than a controlled compromise. |
| Impact | Signals are consistent and point to LOW real-world priority despite the HIGH 7.8 base score. The CVSS vector is AV:L (local only, no network reachability), with PR:L requiring an already-authenticated local user, so this is not a remotely exploitable flaw. EPSS is 0.15% (4th percentile) - negligible exploitation probability - and the CVE is NOT on CISA KEV and has no flagged public exploit, so exploitation status is 'no public exploit identified at time of analysis' (note: the commit message does publish a crash reproducer, pipe_race.c, but that demonstrates the DoS/race, not a weaponized privilege-escalation exploit). Critically, the affected scope is far narrower than the generic 'linux:linux' CPE implies: the fix only matters for kernels built with CONFIG_EYEQ running on MIPS I6500 CPU cores (Mobileye EyeQ5 automotive SoCs), where lld/scd give no ordering guarantees. CONFLICT/CAVEAT: the CVSS claims C:H/I:H/A:H, but the demonstrated impact in the description is a NULL-pointer-dereference kernel oops (availability/DoS); full confidentiality/integrity compromise via broken cmpxchg ordering is plausible (corrupted mutex state can cause arbitrary kernel memory corruption) but is not demonstrated - verify impact scope against the hardware platform before treating this as a C/I threat. Net: a genuine correctness bug on a rare hardware target, not a broad security emergency. |
| Exploit ScenarioDerived | On a Mobileye EyeQ5 (MIPS I6500) system, a local unprivileged process hammers an anonymous pipe with tight concurrent read()/write() loops. Because lld/scd are not ordered on I6500, the CPU reorders a load out of the cmpxchg critical section protecting the pipe mutex, causing a kernel NULL-pointer dereference (oops) and potential memory corruption. A crash reproducer (pipe_race.c) is published in the commit, but no privilege-escalation exploit is known. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
A missing hardware memory-ordering barrier in the Linux kernel's MIPS EYEQ support lets a local, authenticated user crash the kernel on Mobileye EyeQ5 / MIPS I6500 systems. On I6500 cores the lld/scd (LL/SC) instructions provide no ordering guarantees, so arch_cmpxchg() - documented and relied upon as fully ordered - can be reordered and read freed or uninitialized memory, producing a kernel paging fault and oops (observed in anon_pipe_read while stressing an anonymous pipe, whose mutex uses cmpxchg). Exploitation requires CONFIG_EYEQ hardware, local access, and winning a timing/race window; there is no network vector and no impact on x86, ARM, or other MIPS configurations. The fix commit is public and includes a userspace reproducer (pipe_race.c), so publicly available exploit code exists, but no confirmed active exploitation (not in CISA KEV); EPSS is 0.15% (4th percentile), and the observed outcome is a kernel oops rather than a controlled compromise.
RemediationAI
Apply the upstream fix, which is a one-line Kconfig change making CONFIG_EYEQ select CONFIG_WEAK_REORDERING_BEYOND_LLSC. Vendor-released patch: Linux 7.2.8 and Linux 7.3-rc4; the corresponding stable commits are 3f017c2ca8c31a1e135dd87be647096866d6b196 and bbc448c541ed90d52f9ec22f17394304e3bf170e (see https://git.kernel.org/stable/c/3f017c2ca8c31a1e135dd87be647096866d6b196 and https://git.kernel.org/stable/c/bbc448c541ed90d52f9ec22f17394304e3bf170e, with advisory reference https://nvd.nist.gov/vuln/detail/CVE-2026-98228). If upgrading is not immediately possible, the most reliable compensating control is for EYEQ/I6500 system builders to enable CONFIG_WEAK_REORDERING_BEYOND_LLSC manually in the kernel configuration and rebuild - this is exactly what the fix does, so it carries the intended (small) synchronization overhead and no correction risk; it is not available as a runtime toggle. Disabling CONFIG_EYEQ entirely on I6500 hardware removes the buggy code path but also removes EyeQ platform support, making the board unusable for its intended purpose, so it is only viable for hardware that does not need the EYEQ feature set. Reducing the number of untrusted local users, disabling shell/agent access for low-privilege accounts, or sandboxing workloads lowers the probability of an authenticated local attacker triggering the race but does not eliminate the underlying memory-ordering defect and should be treated only as temporary hardening; there is no kernel command-line or sysctl workaround for a missing memory barrier.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected code path is the MIPS LL/SC (load-linked/store-conditional) implementation of atomic primitives, specifically arch_cmpxchg(), which the kernel assumes to be fully ordered. On older MIPS cores LL/SC implied memory ordering, but on MIPS I6500 cores (PrId 0001b028, as seen in the crash log) the lld and scd instructions give no ordering guarantees - the same as any other instruction. Without explicit barriers, the load that follows a successful store-conditional can be reordered above it, so an operation guarded by a cmpxchg-based lock (a mutex in fs/pipe.c in the reproducer) may observe memory that has already been freed or not yet initialized, dereferencing a null/garbage pointer and faulting in kernel mode. The kernel already contains the infrastructure to handle exactly this class of problem: CONFIG_WEAK_REORDERING_BEYOND_LLSC injects sync instructions above and below LL/SC loops. The defect was that CONFIG_EYEQ did not select this option, leaving EYEQ builds on I6500 without the required barriers. The root cause is therefore improper synchronization / a missing hardware memory barrier around an atomic RMW sequence (the input provides no CWE assignment; this maps conceptually to race-condition / improper-locking classes). The practical consequence is memory corruption and kernel instability rather than a directly attacker-controlled primitive, which is why the independent assessment keeps the attack complexity at High despite the 7.8 base score.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local authenticated trigger (AV:L/PR:L); AC:H because exploitation hinges on winning a CPU LL/SC reordering race on specific hardware; broken cmpxchg ordering can corrupt kernel state, justifying C/I/A:H.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
mips: select CONFIG_WEAK_REORDERING_BEYOND_LLSC from CONFIG_EYEQ
On I6500 CPU cores, lld and scd give no ordering guarantees (same as all other instructions). To respect the assumption that arch_cmpxchg() is fully ordered, we must inject sync instructions above and below our lld/scd loops using the already in place WEAK_REORDERING_BEYOND_LLSC infrastructure.
Otherwise, bad things can happen:
[ 34.054496] CPU 3 Unable to handle kernel paging request at virtual address 0000000000000000, epc a80000080838e01c, ra a80000080838dfc4 [ 34.054559] Oops[#1]: [ 34.069561] CPU: 3 UID: 0 PID: 170 Comm: pipe_race Not tainted 7.2.0-rc6-01553-gb73c35220968-dirty #103 VOLUNTARY [ 34.079932] Hardware name: Mobile EyeQ5 MP5 Evaluation board [ 34.085592] $ 0 : 0000000000000000 0000000000000001 0000000000000000 0000000000000000 [ 34.093616] $ 4 : a800000808ee2618 000000000b7a879d 0000000000001000 0000000000000000 [ 34.101638] $ 8 : 0000000000e3f2c9 0000000000000000 a800000808a2a9f8 0000000000000000 [ 34.109660] $12 : a8000008139ffcd8 ffffffff84080018 a80000080837fae0 7878787878787878 [ 34.117682] $16 : a800000807e82940 0000000000001000 0000000000000000 0000000000000000 [ 34.125704] $20 : a800000802920e00 a8000008139ffdf8 a800000802649400 0000000000e3f2c9 [ 34.133726] $24 : 0000000000000006 00000001200406e0 [ 34.141783] $28 : a8000008139fc000 a8000008139ffd10 0000000000e3f2c8 a80000080838dfc4 [ 34.149837] epc : a80000080838e01c anon_pipe_read+0xd4/0x428 [ 34.155697] ra : a80000080838dfc4 anon_pipe_read+0x7c/0x428 [ 34.161549] Status: 140000e3 KX SX UX KERNEL EXL IE [ 34.166551] Cause : 40800408 (ExcCode 02) [ 34.170574] BadVA : 0000000000000000 [ 34.174161] PrId : 0001b028 (MIPS I6500) [ 34.178183] Process pipe_race (pid: 170, threadinfo=000000005ca35720, task=00000000e1013890, tls=000000014ebbb780) [ 34.188568] Stack : a800000802649400 0000000000000000 0000000000000000 a8000008139ffdd0 [ 34.196623] 0000000000000fba a800000808ee0000 0000000000000001 a8000008130c3e80 [ 34.204676] a8000008080d1280 a8000008139ffd58 a8000008139ffd58 1dbd2b22ea1dd500 [ 34.212729] a800000802649400 a800000808ee0000 ffffffffffffffea 0000000000000001 [ 34.220783] 0000000000001000 0000000000000000 00000001200ae518 ffffffffffffffff [ 34.228836] 000000fffbe0e530 a80000080837edf4 000000fffbe0e530 0000000000000000 [ 34.236890] 0000000000000000 0000000000000000 000000014ebb55a0 0000000000001000 [ 34.244943] 0000000000000001 a800000802649400 0000000000000000 0000000000000000 [ 34.252996] 0000000000000000 0000400400000000 0000000000000000 1dbd2b22ea1dd500 [ 34.261049] 00000000140000e3 a800000802649400 a800000802649400 a800000808ee0000 [ 34.269103] ... [ 34.271568] Call Trace: [ 34.274026] [<a80000080838e01c>] anon_pipe_read+0xd4/0x428 [ 34.279533] [<a80000080837edf4>] vfs_read+0x25c/0x318 [ 34.284607] [<a80000080837faac>] ksys_read+0x104/0x138 [ 34.289763] [<a80000080802b9cc>] syscall_common+0x44/0x68 [ 34.295187] [ 34.296689] Code: f84000cf 02209825 de020010 <dc420000> d8400004 02002825 0040f809 02802025 f84000c3 [ 34.306504] [ 34.308099] ---[ end trace 0000000000000000 ]---
My initial reproducer was the xdp-tools test suite. A standalone reproducer would be an lld/scd loop that, when the read is reordered by the CPU, triggers a fault. We can achieve this from userspace by stressing an anonymous pipe, which uses a mutex. Program used:
// SPDX-License-Identifier: GPL-2.0 // pipe_race.c - reproducer for MIPS LL/SC reordering vs fs/pipe.c // // Two userspace processes on an anonymous pipe: // parent = writer: tight write() loop // child = reader: tight read() loop
#define _GNU_SOURCE #include <assert.h> #include <errno.h> #include <sched.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include ---truncated---
Executive ViewAI
A memory-ordering defect in Linux kernel MIPS EYEQ support can allow a local user with access to a Mobileye EyeQ5 / MIPS I6500 system to trigger a kernel paging fault and oops, causing an availability disruption on the affected device. Impact is confined to platforms built on that specific automotive-class SoC and kernel configuration (CONFIG_EYEQ); x86, ARM, and other MIPS deployments are unaffected, and there is no network-exploitable path. Leadership should care primarily where these embedded systems underpin safety-relevant, availability-sensitive products or fleets, and should treat this as a scoped availability risk rather than an enterprise-wide compromise risk.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.
Exploit-DB