Skip to main content
VulnerabilityPublished

CVE-2026-90833: zephyrproject zephyr · Bounds

Affects zephyrproject zephyrSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 7.8 High : upgrade to 4.5.0 or 4.3.2 soon.

Data as of 10 Nov 2026, 22:19 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (zephyr)CVSS 3.17.8
Patch
Available – fixed in 4.5.0, 4.3.2
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Nov 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 10 Nov 2026.

What to do

Upgrade zephyrproject zephyr to 4.5.0 or 4.3.2.

Affected software

ProductAffectedFixed in
zephyrprojectzephyrAffected
  • >=4.4.0 <4.5.0
Fixed in
  • 4.5.0
zephyrprojectzephyrAffected
  • >=2.2.0 <4.3.2
Fixed in
  • 4.3.2
GitHubzephyrpkg:github/zephyrOther threatsAffected
  • >=2.2.0 <4.3.2
  • >=4.4.0 <4.5.0
Fixed in
  • 4.3.2
  • 4.5.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

The simulated EEPROM driver validated access ranges in eeprom_range_is_valid() (drivers/eeprom/eeprom_simulator.c) with a single test, (offset + len) <= config->size. Because offset is a signed off_t and len an unsigned size_t of the same rank, the addition is evaluated in unsigned arithmetic: a negative offset combined with a compensating len wraps the sum back into the accepted range. eeprom_sim_read() and eeprom_sim_write() then memcpy() through the EEPROM(addr) macro, which is plain pointer arithmetic on the driver's static mock_eeprom array, so the copy addresses memory located before that array. eeprom_read() and eeprom_write() are __syscall entry points, and their verification handlers in drivers/eeprom/eeprom_handlers.c check only the device object and the caller's own data buffer (K_SYSCALL_MEMORY_READ/K_SYSCALL_MEMORY_WRITE) — the offset argument is passed to the driver unvalidated. With CONFIG_USERSPACE=y, a CONFIG_EEPROM_SIMULATOR device instance, and the device object granted to a user thread (the usage the in-tree tests/drivers/eeprom/api suite exercises from ZTEST_USER threads), an unprivileged thread could supply a negative offset and have the kernel perform the copy on its behalf. The result is an out-of-bounds read of kernel .bss returned into the caller's buffer and, via the write path, an out-of-bounds write of caller-supplied bytes over kernel memory preceding mock_eeprom. Both the start address and the length of the affected span are attacker-selected, so the primitive is sufficient to corrupt adjacent kernel state and escape the user-mode sandbox. Exposure is limited to builds that instantiate the simulated EEPROM (status = "okay" by default on qemu_x86 and native_sim, otherwise added by a devicetree overlay) together with userspace isolation. The fix rejects negative offsets and performs the remaining bound check without overflow.

References

Community reviews

Loading reviews…