Linux Kernel EUVD-2026-76298

Exploitation requires local shell access with low-level user privileges (PR:L) on a system running QNAP NAS hardware with the qnap-mcu MFD driver compiled and loaded. The attacker must induce a command timeout in qnap_mcu_exec() - either by causing the MCU not to respond within its timeout window or by waiting for an unsolicited MCU message - and the corrupting write must land while the freed frame is still accessible. The driver is only present on QNAP appliances; generic Linux systems do not load it. Remote exploitation is not possible. The race window is narrow and hardware-dependent, limiting opportunistic exploitation. Kernels patched to 6.18.51, 7.2.4, or containing the fix commits are not affected.

The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H is credible for the impact metrics (full C/I/A is appropriate for stack corruption in kernel space) but AC:L is optimistic - exploiting the race requires inducing a command timeout and then timing a late MCU reply or unsolicited message to land in the freed frame, a timing-sensitive condition that independent analysis rates AC:H. EPSS at 0.20% (10th percentile) and absence from CISA KEV are consistent with a hardware-specific kernel driver bug affecting only systems with QNAP MCU hardware under load. No public POC exists. Real-world risk is substantially narrower than the raw CVSS score implies: exploitation is bounded to physical or local-shell access on QNAP NAS appliances, requires triggering a specific timing window, and yields kernel memory corruption whose precise impact depends on what occupies the reclaimed stack.

An attacker with a local shell on a QNAP NAS appliance issues a sequence of MCU commands designed to induce timeouts - for example by saturating the UART bus or exploiting load conditions - causing qnap_mcu_exec() to return with the stale stack pointer. When the MCU subsequently sends a late reply or an unsolicited status packet, the serdev callback writes into the freed stack frame, corrupting a kernel stack belonging to an unrelated thread and potentially redirecting execution. No public proof-of-concept exists; the race is inherently hardware-dependent and timing-sensitive.