Linux Kernel EUVD-2026-35427

Requires the target system to physically include a Honeywell MPRLS0025PA pressure sensor wired over SPI and the mprls0025pa_spi IIO driver to be built and loaded on a Linux kernel between 6.9 and the fixed stable points (6.12.75 / 6.18.14 / 6.19.4 / 7.0). The attacker must have local access (CVSS AV:L) with the ability to interact with the corresponding /sys/bus/iio/devices/iio*/ attributes or /dev/iio:device* node - which on default distributions means root or membership in the iio/udev-configured group, not the PR:N implied by the vector. Limiting factors include the niche hardware requirement, absence of the driver on the vast majority of general-purpose Linux deployments, and lack of any remote attack surface.

The CVSS 3.1 vector AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H scores 8.4 and claims an unauthenticated local attacker can fully compromise confidentiality, integrity, and availability - but this is almost certainly an automated overestimate inherited from the kernel CNA template. Exploitation realistically requires (a) hardware presence of an MPRLS0025PA SPI pressure sensor, (b) the mprls0025pa_spi module being built and loaded, and (c) some local interaction with the driver's IIO sysfs/character interface, which typically requires root or a privileged group. EPSS of 0.02% (5th percentile) and the lack of CISA KEV listing or public PoC are consistent with this being a code-quality fix shipped through normal Linux stable backports rather than an actively exploited issue. PR:N in the vector conflicts with the reality that IIO device nodes are not world-writable by default - defenders should treat this as a low-priority hygiene patch on systems that actually instantiate this sensor.

On an embedded or industrial Linux system that exposes a Honeywell MPRLS0025PA SPI pressure sensor via the iio interface, a local user with access to the IIO sysfs/chardev entries triggers a pressure read, causing the kernel to issue an SPI transfer described by an only-partially-initialized spi_transfer struct. The uninitialized fields can cause the SPI controller to act on stale stack bytes - leaking small amounts of kernel stack memory through observable side effects or producing inconsistent sensor data. No public proof-of-concept exists at time of analysis.