Linux Kernel EUVD-2026-86984

Exploitation requires an NVMe deployment that uses multipath against a SHARED namespace with FDP (Flexible Data Placement) in use, so that nvme_query_fdp_info() runs per-path and two paths concurrently scan the same namespace to populate head->nr_plids/head->plids. Limiting factors: attacker needs LOCAL access (AV:L) and the privileges/ability to induce namespace path scanning (PR:L, e.g., device reconnect/discovery), the affected hardware+config must support FDP with multiple paths to the same namespace, and success depends on winning a narrow concurrency window (a timing race), which constrains reliability despite the AC:L label. Not reachable remotely and not applicable to single-path or non-FDP NVMe configurations.

This is a low-to-moderate priority local availability bug, not an urgent patch-now item. The NVD CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5) scopes impact to availability only - a race on the shared head->nr_plids/head->plids pair that can corrupt the FDP placement-id state and crash or destabilize the kernel, with no confidentiality or integrity impact. All exploitation signals point the same low direction: EPSS is 0.14% (3rd percentile), the CVE is NOT in CISA KEV, and no public exploit was provided - i.e., no public exploit identified at time of analysis. One notable conflict: the input Tags include 'Information Disclosure,' but the CVSS vector sets C:N, so there is no confidentiality impact per the vector - the tag appears mislabeled (CWE-362 and A:H both indicate a race-driven availability/corruption fault, not data disclosure). I also note the vector lists AC:L, yet the root cause is a concurrency race between two multipath scanners, which typically implies a timing-dependent (higher-complexity) trigger; verify whether AC:L is justified. Net: a legitimate kernel hardening fix, but realistic risk is low because it requires local access to a specific hardware/configuration combination rather than remote reach.

A local user or process on a system using NVMe multipath against a shared namespace triggers concurrent path scanning (e.g., device discovery/reconnect) so two paths race to populate the same namespace head's FDP placement-id array. The unsynchronized write/read of nr_plids/plids corrupts that state, destabilizing the kernel and producing a denial of service. No public exploit is identified at time of analysis, and the low-complexity label is in tension with the inherent timing dependence of winning the race.