CVE-2026-17053Medium· 4.4▾ SunlitThe SMBus driver API exposed smbus_smbalert_remove_cb() and smbus_host_notify_remove_cb() as Zephyr syscalls. Their verifiers in drivers/smbus/smbus_handlers.c validated only the dev argument with K_SYSCALL_OBJ(dev, K_OBJ_DRIVER_SMBUS) a…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 24.2 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Oct 2.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.09%
The SMBus driver API exposed smbus_smbalert_remove_cb() and smbus_host_notify_remove_cb() as Zephyr syscalls. Their verifiers in drivers/smbus/smbus_handlers.c validated only the dev argument with K_SYSCALL_OBJ(dev, K_OBJ_DRIVER_SMBUS) and forwarded the caller-supplied struct smbus_callback *cb pointer into kernel-mode driver code without any K_SYSCALL_MEMORY_READ/K_SYSCALL_MEMORY_WRITE validation. A companion change in 2023 had already removed the matching smbus_smbalert_set_cb() / smbus_host_notify_set_cb() syscalls for this reason, but the two removal syscalls were left exposed.
On a build with CONFIG_USERSPACE=y, CONFIG_SMBUS=y and a driver implementing the callback operations (drivers/smbus/intel_pch_smbus.c with CONFIG_SMBUS_INTEL_PCH_SMBALERT/CONFIG_SMBUS_INTEL_PCH_HOST_NOTIFY, or drivers/smbus/smbus_stm32.c with CONFIG_SMBUS_STM32_SMBALERT), any user-mode thread that has been granted the SMBus device object can invoke these syscalls with an arbitrary pointer. The value reaches smbus_callback_remove() in drivers/smbus/smbus_utils.h, which uses it as a node identity against the kernel's sys_slist_t 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 CONFIG_ASSERT=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 CONFIG_USERSPACE, and no impact on configurations that do not enable an SMBus driver with SMBALERT or Host Notify support.
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-19947Medium· 5.3Missing kernel object permission check in devmux syscalls allows unprivileged user threads to retarget a device multiplexer
CVE-2026-19742Low· 3.7IPv6 stable and temporary interface identifiers derived from a non-cryptographic PRNG secret key
CVE-2026-81039Medium· 4.3Bluetooth Host connection reservation leak when multiple connectable advertising sets share an identity
CVE-2026-81038High· 7.1Bluetooth OTS server discloses uninitialized stack memory in failed Calculate Checksum responses
CVE-2026-82390Low· 3.7Cross-session AES key confusion in the Espressif ESP32 hardware crypto driver
CVE-2026-82388Medium· 5.3Use of a released HFP HF object after a failed RFCOMM connect in the Bluetooth Classic host