{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-90834", "assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad", "state": "PUBLISHED", "assignerShortName": "zephyr", "dateReserved": "2026-09-13T19:23:00.663Z", "datePublished": "2026-11-10T22:07:45.167Z", "dateUpdated": "2026-11-10T22:07:45.167Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad", "shortName": "zephyr", "dateUpdated": "2026-11-10T22:07:45.167Z"}, "title": "UART wide-data syscall verifiers check the 8-bit driver op, allowing a user-mode thread to trigger a NULL function-pointer call in kernel mode", "descriptions": [{"lang": "en", "value": "The user-mode syscall verifiers for the 16-bit (\"wide data\") UART API in drivers/serial/uart_handlers.c validated the wrong driver operation. z_vrfy_uart_poll_out_u16(), z_vrfy_uart_tx_u16() and z_vrfy_uart_rx_enable_u16() each ran K_SYSCALL_DRIVER_UART() against the 8-bit op (poll_out, tx, rx_enable) rather than the 16-bit op that the corresponding implementation dereferences (poll_out_u16, tx_u16, rx_enable_u16). z_impl_uart_poll_out_u16(), z_impl_uart_tx_u16() and z_impl_uart_rx_enable_u16() in include/zephyr/drivers/uart/uart_internal.h call their op unconditionally, with no NULL guard of their own, because the verifier is supposed to have established that the op exists.\n\nCONFIG_UART_WIDE_DATA is an application-selectable option that no driver selects, and only a handful of the serial drivers in the tree implement any _u16 operation; every other driver leaves those struct uart_driver_api members NULL while still providing the 8-bit ops the old check inspected. In a build with CONFIG_USERSPACE and CONFIG_UART_WIDE_DATA (plus CONFIG_UART_ASYNC_API for the uart_tx_u16() and uart_rx_enable_u16() variants), an unprivileged user-mode thread that legitimately holds access to such a UART device object can invoke the _u16 syscall: the object, permission and op checks all pass, and the kernel-side implementation then performs an indirect call through a NULL function pointer while running at supervisor privilege.\n\nThe result is a CPU exception taken in kernel context instead of the intended K_OOPS or -ENOSYS return. With the default k_sys_fatal_error_handler() this halts the system (or warm-reboots it under CONFIG_RESET_ON_FATAL_ERROR), so a thread confined by the userspace sandbox can deny service to the whole device \u2014 a capability the user-mode privilege boundary is specifically meant to withhold. The call target is a fixed NULL, so there is no attacker-controlled code execution and no memory disclosure; the separate K_SYSCALL_MEMORY_ARRAY_READ()/K_SYSCALL_MEMORY_ARRAY_WRITE() bounds checks on the caller's buffer were and remain correct. The fix points each verifier at the matching _u16 op, using a plain K_SYSCALL_OBJ() object check where the op does not exist or where the implementation already tests it for NULL."}], "affected": [{"vendor": "zephyrproject", "product": "zephyr", "collectionURL": "https://github.com/zephyrproject-rtos/zephyr", "packageName": "zephyr", "defaultStatus": "unaffected", "programFiles": ["drivers/serial/uart_handlers.c"], "programRoutines": [{"name": "z_vrfy_uart_poll_out_u16"}, {"name": "z_vrfy_uart_rx_enable_u16"}, {"name": "z_vrfy_uart_tx_u16"}], "versions": [{"version": "3.0.0", "status": "affected", "versionType": "semver", "lessThan": "4.3.2"}, {"version": "4.4.0", "status": "affected", "versionType": "semver", "lessThan": "4.5.0"}]}], "references": [{"url": "https://github.com/zephyrproject-rtos/zephyr/commit/3c13bfd3d3ccdceeb51b884fed5a8d2a49475484", "name": "Fix commit", "tags": ["patch"]}, {"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xvwx-ww79-r346", "name": "GHSA-xvwx-ww79-r346"}], "metrics": [{"format": "CVSS", "cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "baseScore": 5.5, "baseSeverity": "MEDIUM"}}], "problemTypes": [{"descriptions": [{"lang": "en", "description": "memory-safety", "cweId": "CWE-476", "type": "CWE"}]}], "x_generator": {"engine": "cvelib 1.8.0"}}}}

{}

{"affected": [{"affectedData": [{"collectionURL": "https://github.com/zephyrproject-rtos/zephyr", "defaultStatus": "unaffected", "packageName": "zephyr", "product": "zephyr", "programFiles": ["drivers/serial/uart_handlers.c"], "programRoutines": [{"name": "z_vrfy_uart_poll_out_u16"}, {"name": "z_vrfy_uart_rx_enable_u16"}, {"name": "z_vrfy_uart_tx_u16"}], "vendor": "zephyrproject", "versions": [{"lessThan": "4.3.2", "status": "affected", "version": "3.0.0", "versionType": "semver"}, {"lessThan": "4.5.0", "status": "affected", "version": "4.4.0", "versionType": "semver"}]}], "source": "[email protected]"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "The user-mode syscall verifiers for the 16-bit (\"wide data\") UART API in drivers/serial/uart_handlers.c validated the wrong driver operation. z_vrfy_uart_poll_out_u16(), z_vrfy_uart_tx_u16() and z_vrfy_uart_rx_enable_u16() each ran K_SYSCALL_DRIVER_UART() against the 8-bit op (poll_out, tx, rx_enable) rather than the 16-bit op that the corresponding implementation dereferences (poll_out_u16, tx_u16, rx_enable_u16). z_impl_uart_poll_out_u16(), z_impl_uart_tx_u16() and z_impl_uart_rx_enable_u16() in include/zephyr/drivers/uart/uart_internal.h call their op unconditionally, with no NULL guard of their own, because the verifier is supposed to have established that the op exists.\n\nCONFIG_UART_WIDE_DATA is an application-selectable option that no driver selects, and only a handful of the serial drivers in the tree implement any _u16 operation; every other driver leaves those struct uart_driver_api members NULL while still providing the 8-bit ops the old check inspected. In a build with CONFIG_USERSPACE and CONFIG_UART_WIDE_DATA (plus CONFIG_UART_ASYNC_API for the uart_tx_u16() and uart_rx_enable_u16() variants), an unprivileged user-mode thread that legitimately holds access to such a UART device object can invoke the _u16 syscall: the object, permission and op checks all pass, and the kernel-side implementation then performs an indirect call through a NULL function pointer while running at supervisor privilege.\n\nThe result is a CPU exception taken in kernel context instead of the intended K_OOPS or -ENOSYS return. With the default k_sys_fatal_error_handler() this halts the system (or warm-reboots it under CONFIG_RESET_ON_FATAL_ERROR), so a thread confined by the userspace sandbox can deny service to the whole device \u2014 a capability the user-mode privilege boundary is specifically meant to withhold. The call target is a fixed NULL, so there is no attacker-controlled code execution and no memory disclosure; the separate K_SYSCALL_MEMORY_ARRAY_READ()/K_SYSCALL_MEMORY_ARRAY_WRITE() bounds checks on the caller's buffer were and remain correct. The fix points each verifier at the matching _u16 op, using a plain K_SYSCALL_OBJ() object check where the op does not exist or where the implementation already tests it for NULL."}], "id": "CVE-2026-90834", "lastModified": "2026-11-10T22:21:14.570", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "[email protected]", "type": "Secondary"}]}, "published": "2026-11-10T22:21:14.460", "references": [{"source": "[email protected]", "url": "https://github.com/zephyrproject-rtos/zephyr/commit/3c13bfd3d3ccdceeb51b884fed5a8d2a49475484"}, {"source": "[email protected]", "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xvwx-ww79-r346"}], "sourceIdentifier": "[email protected]", "vulnStatus": "Awaiting Analysis", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-476"}], "source": "[email protected]", "type": "Secondary"}]}

{}

{}