CVE-2024-26978 - Null Pointer Dereference Fixed in Linux Kernel max310x I2C Driver

A recent security vulnerability has been identified and addressed in the Linux kernel, specifically in the max310x serial device driver. This flaw, assigned CVE-2024-26978, could allow a user to trigger a Null Pointer Dereference when instantiating certain I2C devices from user space, potentially leading to a kernel panic and denial of service.

Let's break down what happened, how it can be exploited, see real code snippets involved, and learn how it was fixed.

The Vulnerability: How Did This Happen?

The max310x family includes chips like the max14830, which are UART expander ICs used over SPI or I2C. The Linux kernel provides a driver for these chips (max310x.c). When a user tries to instantiate an I2C device via the sysfs interface, like so:

echo max14830 x60 > /sys/bus/i2c/devices/i2c-2/new_device

If the driver doesn't properly validate the attributes of the new device, it can attempt to access a NULL pointer during probe, causing a kernel oops.

Here's what it looks like in kernel logs (dmesg)

Unable to handle kernel NULL pointer dereference at virtual address 000000000000002
...
Call trace:
    max310x_i2c_probe+x48/x170 [max310x]
    i2c_device_probe+x150/x2a
...

In plain English: the kernel tried to use some data tied to the new device, but it was actually NULL, leading to a crash.

Any user with permission to write to sysfs can trigger the bug with a single line

echo max14830 x60 > /sys/bus/i2c/devices/i2c-2/new_device

Why does this work?

When this command is executed, the kernel's I2C subsystem calls the probe function (max310x_i2c_probe()). If the provided device type (devtype) is missing or invalid (often the case for manually instantiated devices), the probe function uses a NULL pointer and dereferences it, making the kernel crash.

In the original code, devtype could be unchecked

const struct max310x_devtype *devtype = id->driver_data;
/* devtype may be NULL if not set properly */
pdata = devtype->pdata;

At this stage, devtype could be NULL, producing exactly the error described above.

The fix is to add a simple safety check

if (!devtype) {
    dev_err(&client->dev, "Invalid device type\n");
    return -ENODEV;
}

This aborts the probe gracefully if the device type is missing or bad, and logs a clear error.

Full Diff Snippet

Here is the relevant patch, based on the original kernel commit (source):

@@ -500,6 +500,10 @@ static int max310x_i2c_probe(struct i2c_client *client,
     const struct i2c_device_id *id = i2c_match_id(max310x_i2c_id, client);
     const struct max310x_devtype *devtype = id->driver_data;
 
+    if (!devtype) {
+        dev_err(&client->dev, "Invalid device type\n");
+        return -ENODEV;
+    }
 
     .... // rest of probe function

With this fix, the kernel cleanly rejects invalid instantiations and continues running safely.

Reference Links

- Kernel Patch Commit
- oss-security post
- CVE-2024-26978 at cvelist (will update as public)

Update Your Kernel: If you use the max310x driver, update to a kernel with this patch.

- Restrict Sysfs Access: Ensure only trusted users can write to /sys/bus/i2c/devices/*.

Summary

CVE-2024-26978 highlights how even small device driver bugs can have big stability impacts. Thanks to quick work by kernel developers, the issue is fixed by checking for NULL pointers before using them. Always keep your system up to date, especially if it’s running hardware drivers that may be exposed to local users!

Timeline

Published on: 05/01/2024 06:15:15 UTC
Last modified on: 07/03/2024 01:50:11 UTC