CVE-2026-17053: SMBus callback-removal syscalls accept an unvalidated user pointer, letting user threads manipulate kernel callback state
The SMBus driver API exposed smbussmbalertremovecb() and smbushostnotifyremovecb() as Zephyr syscalls. Their verifiers in drivers/smbus/smbushandlers.c validated only the dev argument with KSYSCALLOBJ(dev, KOBJDRIVERSMBUS) and forwarded the caller-supplied struct smbuscallback cb pointer into kernel-mode driver code without any KSYSCALLMEMORYREAD/KSYSCALLMEMORYWRITE validation. A companion change in 2023 had already removed the matching smbussmbalertsetcb() / smbushostnotifysetcb() syscalls for this reason, but the two removal syscalls were left exposed.
On a build with CONFIGUSERSPACE=y, CONFIGSMBUS=y and a driver implementing the callback operations (drivers/smbus/intelpchsmbus.c with CONFIGSMBUSINTELPCHSMBALERT/CONFIGSMBUSINTELPCHHOSTNOTIFY, or drivers/smbus/smbusstm32.c with CONFIGSMBUSSTM32SMBALERT), any user-mode thread that has been granted the SMBus device object can invoke these syscalls with an arbitrary pointer. The value reaches smbuscallbackremove() in drivers/smbus/smbusutils.h, which uses it as a node identity against the kernel's sysslistt of registered callbacks.
The consequence is that an unprivileged thread can unregister an SMBALERT or Host Notify callback that a supervisor-mode component registered, silently disabling alert handling for the rest of the system; because Zephyr images have fixed symbol addresses and the syscall returns 0 on a hit versus -ENOENT on a miss, the target address is both derivable and searchable. In builds with CONFIGASSERT=y the ASSERT(callback->handler, ...) check additionally dereferences the caller-supplied address in supervisor mode, so a bogus pointer raises a kernel-mode fault and a fatal system error, and the fault/no-fault outcome discloses which addresses are mapped.
The fix removes both syscall entry points, demoting the two functions to ordinary static inline calls so that callback list manipulation is available only to supervisor-mode code. There is no impact on builds without CONFIGUSERSPACE, and no impact on configurations that do not enable an SMBus driver with SMBALERT or Host Notify support.
Affected Software
Event History
Frequently Asked Questions
Which Zephyr builds are exposed?
Exposure requires CONFIG_USERSPACE=y and CONFIG_SMBUS=y, plus an SMBus driver that implements the callback operations. The identified configurations are the Intel PCH SMBus driver with CONFIG_SMBUS_INTEL_PCH_SMBALERT or CONFIG_SMBUS_INTEL_PCH_HOST_NOTIFY, and the STM32 SMBus driver with CONFIG_SMBUS_STM32_SMBALERT.
What access does an attacker need?
An attacker needs to execute a user-mode thread that has been granted access to the relevant SMBus device object. That thread can call either callback-removal syscall with an arbitrary callback pointer.
Does enabling SMBus alone make a system affected?
No. The affected syscall path also depends on userspace being enabled and on a listed SMBus driver and callback feature being configured.
What can be done if an update cannot be applied immediately?
Remove SMBus device-object access from untrusted user-mode threads, since such a grant is required to invoke the affected syscalls. Where feasible, rebuild without CONFIG_USERSPACE, CONFIG_SMBUS, or the affected Intel PCH or STM32 callback feature configurations.
How can an administrator identify potentially exposed systems?
Review the build configuration for CONFIG_USERSPACE=y, CONFIG_SMBUS=y, and the affected Intel PCH SMBALERT/HOST_NOTIFY or STM32 SMBALERT options. Also review whether user-mode threads have been granted the corresponding SMBus device object.