Description
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.
Published: 2026-10-01
Score: 4.4 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Unauthorized modification of kernel callback state leading to denial of SMBALERT/Host Notify functionality
Action: Apply patch
AI Analysis

Impact

The vulnerability arises from SMBus driver syscalls that accept an arbitrary user pointer without validating memory access. An unprivileged thread that has been granted a SMBus device object can invoke these syscalls to pass any pointer, which the kernel then uses to identify and remove a callback from a protected list. This silently disables alert handling for the system, creating a denial‑of‑service condition or providing an attacker a means to suppress critical hardware notifications. The flaw does not grant code execution, but it can undermine system stability and monitoring.

Affected Systems

The issue affects Zephyr RTOS builds that enable CONFIG_USERSPACE, CONFIG_SMBUS and a driver providing SMBALERT or Host Notify support, such as the Intel PCH SMBus driver (CONFIG_SMBUS_INTEL_PCH_SMBALERT/CONFIG_SMBUS_INTEL_PCH_HOST_NOTIFY) or the STM32 SMBus driver (CONFIG_SMBUS_STM32_SMBALERT). Systems without CONFIG_USERSPACE or without SMBus drivers are not impacted.

Risk and Exploitability

The CVSS score of 4.4 reflects a low severity assessment. The EPSS score is not available, and the vulnerability is not listed in CISA’s KEV catalog. Exploitation requires local user‑space access to an SMBus device object, meaning the threat is limited to processes running on the same machine that can obtain that object. Attackers can simply call the exposed removal syscalls with a crafted pointer, causing the callback list to be altered and silent denial of alert handling. The impact is localized to the affected build, but it can affect all components that rely on SMBALERT or Host Notify callbacks.

Generated by OpenCVE AI on October 1, 2026 at 17:17 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update Zephyr RTOS to a release that includes commit 331df881a8b8cb4296699a8251c9fd74a4308f3d, which removes the vulnerable syscalls and restricts callback manipulation to privileged code.
  • If updating is not immediately possible, rebuild the kernel with CONFIG_USERSPACE disabled or remove SMBALERT/Host Notify support from the SMBus driver to prevent unprivileged removal.
  • Monitor for attempts to invoke smbus_smbalert_remove_cb or smbus_host_notify_remove_cb syscalls using system logs or kernel audit to detect attempted manipulation.

Generated by OpenCVE AI on October 1, 2026 at 17:17 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 02 Oct 2026 09:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Thu, 01 Oct 2026 16:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Thu, 01 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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.
Title SMBus callback-removal syscalls accept an unvalidated user pointer, letting user threads manipulate kernel callback state
Weaknesses CWE-862
References
Metrics cvssV3_1

{'score': 4.4, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-10-01T16:03:31.409Z

Reserved: 2026-07-24T13:31:06.974Z

Link: CVE-2026-17053

cve-icon Vulnrichment

Updated: 2026-10-01T16:03:27.666Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-10-01T16:17:41.510

Modified: 2026-10-02T18:44:11.270

Link: CVE-2026-17053

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-01T17:30:10Z

Weaknesses