CVE-2026-90833: Signed offset bypasses bounds check in simulated EEPROM driver, allowing out-of-bounds kernel memory read and write from user mode

The simulated EEPROM driver validated access ranges in eepromrangeisvalid() (drivers/eeprom/eepromsimulator.c) with a single test, (offset + len) <= config->size. Because offset is a signed offt and len an unsigned sizet 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. eepromsimread() and eepromsimwrite() then memcpy() through the EEPROM(addr) macro, which is plain pointer arithmetic on the driver's static mockeeprom array, so the copy addresses memory located before that array.

eepromread() and eepromwrite() are syscall entry points, and their verification handlers in drivers/eeprom/eepromhandlers.c check only the device object and the caller's own data buffer (KSYSCALLMEMORYREAD/KSYSCALLMEMORYWRITE) — the offset argument is passed to the driver unvalidated. With CONFIGUSERSPACE=y, a CONFIGEEPROMSIMULATOR device instance, and the device object granted to a user thread (the usage the in-tree tests/drivers/eeprom/api suite exercises from ZTESTUSER 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 mockeeprom. 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 qemux86 and nativesim, otherwise added by a devicetree overlay) together with userspace isolation.

The fix rejects negative offsets and performs the remaining bound check without overflow.