CVE-2024-26978

What it actually does

The max310x_i2c_probe function dereferences a NULL devtype pointer during I2C device instantiation from userspace via sysfs, resulting in a kernel NULL pointer dereference and immediate crash.

Why it matters to the business

Local users can trigger an immediate kernel crash and denial of service on systems running affected kernel versions; the issue is limited to systems using the max310x driver and does not allow code execution or privilege escalation.

How an attack unfolds

An attacker with local shell access writes a device name and address to the I2C new_device sysfs file, causing the kernel to call i2c_device_probe which invokes max310x_i2c_probe without a valid devtype, leading to the NULL dereference.

How to fix it

Upgrade to a fixed kernel version such as 5.4.274 or apply the commit 7d271b798add90c6196539167c019d0817285cf0 (or equivalent backports) that adds the devtype validity check before probe proceeds.

How to confirm the fix worked

Confirm the running kernel contains the devtype check in max310x_i2c_probe; attempt the sysfs instantiation on a test system and verify it returns a meaningful error instead of crashing; monitor kernel logs for absence of the original NULL dereference oops.

Typical attack path

1. Obtain local user access on a Linux system using the max310x I2C driver
2. Identify an I2C bus and write the device string (e.g., max14830 0x60) to /sys/bus/i2c/devices/i2c-N/new_device
3. Trigger the probe path that lacks a devtype validity check
4. Cause kernel panic via NULL pointer dereference

How to detect it

Search kernel logs and dmesg for the strings 'Unable to handle kernel NULL pointer dereference' combined with 'max310x_i2c_probe' and the call trace referencing i2c_device_probe; look for sysfs write events to new_device files on I2C buses shortly before the crash.

• max310x_i2c_probe+0x48/0x170
• Unable to handle kernel NULL pointer dereference at virtual address
• echo max14830 0x60 > /sys/bus/i2c/devices/i2c-*/new_device

What your security team should do

• Prioritize patching production kernels that expose I2C sysfs to untrusted users
• Restrict write access to /sys/bus/i2c/devices/*/new_device via file permissions or LSM policy until patched
• Reboot systems after applying the fixed kernel packages