---
id: "CVE-2026-90833"
page: "https://infrastack.ai/live/CVE-2026-90833"
kind: "vulnerability"
aliases: ["CVE-2026-90833"]
title: "Zephyr: simulated EEPROM driver lets a user thread write kernel memory"
severity: "high"
cvss: 7.8
epss: null
exploited: false
status: "open"
category: "runtime"
products: [{"name": "zephyr", "fixed": ["4.3.2", "4.5.0"], "affected": ">= 2.2.0, < 4.3.2; >= 4.4.0, < 4.5.0", "ecosystem": "vendor"}]
ecosystems: []
tags: ["embedded", "runtime", "userspace", "zephyr"]
not_affected_if: ["hardware-eeprom-only", "no-eeprom-simulator", "no-userspace"]
published_at: "2026-11-10T22:21:14+00:00"
first_seen_at: "2026-11-10T22:27:31+00:00"
updated_at: "2026-11-10T22:37:48+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90833", "first_seen_at": "2026-11-10T22:27:31+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-10T22:37:48+00:00"}]
exploit_sources: []
---

# Zephyr: simulated EEPROM driver lets a user thread write kernel memory

Link for people: https://infrastack.ai/live/CVE-2026-90833 (this .md is for agents)

Zephyr's simulated EEPROM driver checks (offset + len) <= size in unsigned arithmetic, so a negative offset wraps past validation. A user-mode thread can then read or write kernel memory before the mock_eeprom array through the eeprom_read/eeprom_write syscalls. Fixed in 4.3.2 and 4.5.0.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:zephyr affected >= 2.2.0, < 4.3.2; >= 4.4.0, < 4.5.0 fixed 4.3.2, 4.5.0

## How to check

- Your build is exposed only if all hold: CONFIG_EEPROM_SIMULATOR=y (default y when a zephyr,sim-eeprom node is enabled), CONFIG_USERSPACE=y, and the EEPROM device is granted to user threads (k_object_access_grant).
- Check the devicetree: the sim-eeprom node has status = "okay" (default on qemu_x86 and native_sim, otherwise added by overlay).
- Check your Zephyr version: affected >= 2.2.0 and < 4.3.2, or >= 4.4.0 and < 4.5.0.
- Also check any local branch: drivers/eeprom/eeprom_simulator.c should reject offset < 0 in eeprom_range_is_valid().

## Fix

Upgrade Zephyr to 4.3.2 (4.3 line) or 4.5.0. Patch commit ce2ec9b3a34d (main PR #118774); backport PRs merged to v4.4-branch (#119415), v4.3-branch (#119414), v3.7-branch (#119416), but the advisory lists patched releases only as 4.3.2 and 4.5.0. 4.4.x before 4.5.0 stays listed as affected.

## Timeline

- 2026-11-10T22:27:31+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-90833
- 2026-11-10T22:37:48+00:00 analyst — Read GHSA-vf6j-hcx8-44vh and commit ce2ec9b: patched 4.3.2/4.5.0, affected ranges stated; no exploitation or PoC found (not searched social; obscure embedded CVE).

## Documents

- [advisory] Vendor advisory: github.com https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-vf6j-hcx8-44vh
- [fix] Patch: github.com https://github.com/zephyrproject-rtos/zephyr/commit/ce2ec9b3a34d71f52f5d1d7491b91393e334713e

## From the sources

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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_