CVE-2024-26593 - Digging Into the Linux Kernel i2c-i801 Block Process Call Bug

The Linux kernel powers everything from laptops to data centers, and its drivers ensure smooth hardware communications. But sometimes, hidden bugs slip through. One of these, now patched, is CVE-2024-26593, a vulnerability in the i2c-i801 driver dealing with block process call transactions. This long-read post breaks down the issue in simple terms, shows what went wrong in code, links you to sources, and talks about possible exploitation.

What Is CVE-2024-26593?

CVE-2024-26593 is a flaw in the Linux kernel's Intel I2C i801 driver. The I2C bus is used for devices like temperature sensors and EEPROM chips. The vulnerability lies in how the driver handles "block process call" transactions, a special way to send and receive a block of data in a single operation.

The driver forgot the second reset.

As a result, when the driver reads back the data sent from the device, it pulls from the wrong place in the buffer—possibly leaking wrong or stale information.

Let's glance at the old code snippet (simplified for clarity)

// ... inside i801_block_transaction() for I2C_SMBUS_BLOCK_PROC_CALL

/* Reset the block buffer index before writing */
outb(SMBHSTCNT_BLOCK, SMBHSTCNT);

for (i = ; i < write_len; i++)
    outb(write_buf[i], SMBHSTDAT);

/* Start the transaction */
outb(ctrl, SMBHSTCNT);

/* Wait for completion, check errors omitted ... */

/* Read incoming data - BUG: missing buffer index reset here! */
for (i = ; i < read_len; i++)
    read_buf[i] = inb(SMBHSTDAT);

The patch added the required "reset" before reading

/* Second reset before reading incoming data! */
outb(SMBHSTCNT_BLOCK, SMBHSTCNT);

for (i = ; i < read_len; i++)
    read_buf[i] = inb(SMBHSTDAT);

References

- Upstream Linux kernel patch
- CVE-2024-26593 entry on NIST
- Intel 8 Series/C220 Chipset Family Platform Controller Hub Datasheet
- Linux i2c-i801 driver source

Is This Vulnerable In The Real World?

This bug requires direct access to the i2c-i801 device driver, meaning you would probably need to be root or have CAP_SYS_RAWIO-level privileges. An unprivileged attacker can't use this directly, but...

On systems where i2c-dev or similar gives userland apps access to i2c busses, misconfigured permissions could enable exploitation. For example, on desktops with third-party tools or monitoring apps that have i2c access, a user could craft calls to the buggy block process call operation.

What Could Be Exploited?

- Data leakage: The system might read out stale values or wrong data from the buffer. This could potentially leak information to userspace if block transactions are being used in sensitive sensor monitoring or firmware communication.
- Data integrity: An attacker might trick software into believing the wrong values were retrieved from a hardware device, causing errors or even system instability.

Proof-of-Concept: A Dangerous Example

Suppose a misconfigured system lets users run custom I2C commands. A malicious user could write this Python script using python-smbus or similar tools (assuming kernel is unpatched and permissions are lax):

import smbus

# WARNING: dangerous, don't use on production!
bus_id =   # Usually  or 1
device_addr = x50  # Change to actual device on your I2C bus

bus = smbus.SMBus(bus_id)

# Attempt block process call (the vulnerable operation)
write_block = [x12, x34, x56]
# This should result in correct data from device.
# Unpatched, might mix up read buffer and return bogus/stale/other memory.
resp_block = bus.block_process_call(device_addr, x00, write_block)
print("Got block:", resp_block)

On vulnerable kernels, the data returned could be unpredictable, possibly even unrelated to the sent command. With careful timing and kernel knowledge, one may craft further exploitation.

Conclusion & Takeaway

CVE-2024-26593 was a subtle but impactful lesson in following hardware documentation closely—even for rarely-used edge cases in kernel drivers. For most desktop and server users, this bug was harmless due to privilege boundaries, _unless_ I2C access was misconfigured.

Are you at risk?
If you are running a Linux system with Intel chipsets and have enabled i2c-i801 or i2c-dev for userspace, apply kernel updates—especially if you allow users to run custom I2C commands!

Lock down hardware access to privileged users only.

If you want to geek out further:
- See the kernel patch discussion thread
- Read the Linux I2C documentation

Timeline

Published on: 02/23/2024 10:15:07 UTC
Last modified on: 04/19/2024 17:58:44 UTC