Zephyr RTOS EUVD-2026-90880

Requires a Zephyr build with CONFIG_USERSPACE=y AND CONFIG_SMBUS=y AND an SMBus driver implementing the callback operations - specifically drivers/smbus/intel_pch_smbus.c with CONFIG_SMBUS_INTEL_PCH_SMBALERT or CONFIG_SMBUS_INTEL_PCH_HOST_NOTIFY, or drivers/smbus/smbus_stm32.c with CONFIG_SMBUS_STM32_SMBALERT. The attacker must be a local user-mode thread that has already been granted the SMBus device object (PR:L, AV:L). There is explicitly NO impact on builds without CONFIG_USERSPACE and NO impact on configurations that do not enable an SMBus driver with SMBALERT or Host Notify support. The CONFIG_ASSERT=y fault/DoS and address-disclosure path additionally depends on assertions being compiled in.

This is a genuinely low-to-moderate risk, config-gated local privilege/integrity issue - the CVSS of 4.4 is honest, not inflated. The vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L correctly captures that exploitation is LOCAL (AV:L) by an already-authenticated low-privileged user-mode thread (PR:L) with no user interaction, producing only partial integrity and availability impact and no confidentiality loss per the vendor. There is no EPSS score, no CISA KEV listing, and no public exploit code identified at time of analysis, so there is no public exploit identified at time of analysis. The key risk-dampening factor is not the CVSS metrics but the narrow prerequisite surface: the vulnerable syscalls only exist and matter on builds with CONFIG_USERSPACE=y, CONFIG_SMBUS=y, and a specific driver (Intel PCH or STM32) compiled with SMBALERT/Host-Notify support, and the attacking thread must already have been granted the SMBus device object. No signals conflict here - low real-world risk is consistent across CVSS, missing EPSS/KEV, and the absence of a POC. Note the description also mentions a minor address-mapping side channel (fault vs no-fault, and 0 vs -ENOENT return codes), which arguably warrants C:L; the vendor nonetheless scored C:N, treating it as negligible.

On a Zephyr image built with CONFIG_USERSPACE, CONFIG_SMBUS, and an SMBALERT/Host-Notify-capable driver, a low-privileged user-mode thread that holds the SMBus device object invokes smbus_smbalert_remove_cb() or smbus_host_notify_remove_cb() with an attacker-chosen pointer; because images have fixed symbol addresses and the syscall returns 0 on a hit versus -ENOENT on a miss, the attacker searches for and unregisters a callback a supervisor component registered, silently disabling alert handling. Alternatively, on a CONFIG_ASSERT=y build, supplying a bogus pointer causes the __ASSERT(callback->handler, ...) check to dereference it in supervisor mode, triggering a kernel-mode fault and fatal system error (DoS), while the fault/no-fault outcome leaks which addresses are mapped. No public exploit code is known, and exploitation is local and requires the prior grant of the SMBus device object.