CVE-2022-48806

What it actually does

The ee1004_eeprom_read function fails to cap the read length before passing it to i2c_smbus_read_i2c_block_data_or_emulated, allowing a u8 cast of a 256-byte request to wrap and trigger an out-of-bounds read or write during EEPROM access on I2C buses.

Why it matters to the business

Systems running affected kernels with SPD or other EEPROM devices may experience crashes, memory corruption, or unexpected hardware access when user-space tools attempt full EEPROM dumps, increasing downtime and patch urgency for servers and embedded devices using the Linux kernel.

How an attack unfolds

An attacker with local access or the ability to trigger user-space EEPROM reads (for example via sensors or configuration tools) supplies a read request that crosses a 256-byte boundary; the resulting length wrap in the I2C block read path leads to memory corruption that can be leveraged for privilege escalation or denial of service on affected kernels.

How to fix it

Upgrade the Linux kernel to a version containing commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be or later; rebuild and reboot all affected systems. Where immediate patching is impossible, restrict unprivileged access to EEPROM sysfs or I2C device nodes.

How to confirm the fix worked

Confirm the running kernel contains commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be by checking /proc/version or the kernel build log, then verify that attempts to read 256 bytes from the EEPROM device no longer trigger oversized transfers.

Typical attack path

1. Identify a system exposing EEPROM-backed devices via I2C
2. Trigger or coerce a full 256-byte or larger EEPROM read from user space
3. Cause the u8 length overflow inside ee1004_eeprom_read
4. Exploit resulting memory corruption for code execution or crash

How to detect it

Review kernel logs for I2C or ee1004 error messages around the time of crashes, and inspect any user-space processes that opened I2C devices immediately before faults; correlate with audit logs of EEPROM sysfs access.

What your security team should do

• Prioritize kernel upgrades on all systems exposing I2C EEPROM devices within the next maintenance window
• Audit user-space processes that directly access /sys/bus/i2c or /dev/i2c-* for full EEPROM reads
• Enable kernel hardening options such as CONFIG_HARDENED_USERCOPY until patches are deployed