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…