In early 2024, a critical vulnerability was discovered and promptly fixed in the Linux kernel’s Qualcomm Atheros at803x PHY driver. This bug (CVE-2024-26942) could cause a kernel panic—a total system crash—due to a NULL pointer dereference during the probing phase of some Atheros Ethernet PHY chips. Below, we break down what happened, how it can be exploited, detailed technical steps, and what you can do to protect your systems.

Simple Summary

A code error in the at803x Ethernet PHY (physical layer) driver in Linux could let a malicious actor crash your system during hardware initialization. This happens because the code tries to access and write to memory that hasn’t been set up yet, which in programming terms, is called a NULL pointer dereference.

Technical Breakdown

When the at803x driver was split into different functions to support multiple hardware types, a sequence bug happened. The driver referenced a data structure called priv before it was properly assigned during the hardware probe step. As a result, accessing priv->is_100basex and priv->is_fiber could corrupt memory or trigger an instant kernel panic, crashing the system.

Problematic Code Snippet

static int at8031_config_init(struct phy_device *phydev)
{
    struct at803x_priv *priv = phydev->priv; // <--- priv not allocated yet!

    priv->is_100basex = false; // NULL deref!
    priv->is_fiber = false;

    /* ... other config ... */
}

Here, phydev->priv is being used before the memory for it is allocated, so priv is NULL. Writing to priv->is_100basex causes a kernel panic.

What Was Fixed

The solution is to only get the priv pointer after the at803x_probe() has run, because that routine actually allocates the memory for priv.

Fixed Code Snippet

static int at8031_config_init(struct phy_device *phydev)
{
    int ret;

    ret = at803x_probe(phydev); // Priv is allocated here
    if (ret)
        return ret;

    struct at803x_priv *priv = phydev->priv; // Safe to use now

    priv->is_100basex = false;
    priv->is_fiber = false;

    /* ... other config ... */
}

Who’s Affected?

- Any Linux system (x86, ARM, etc) using at803x-family Ethernet PHY chips (for example, in routers, network devices, embedded boards).

Attack Vector

This is a local bug: an attacker who can trigger device (re-)initialization, such as by manipulating the hardware directly (e.g., physically unplugging and replugging the PHY device, or causing a software reset, or passing custom device trees), can crash the kernel.

Exploit Details

- Step 1: Trigger a device probe (by inserting/removing hardware, using hotplug events, or custom device-tree overlays).

Step 2: The kernel’s driver will reference priv before allocation.

- Step 3: A write to priv->is_100basex or priv->is_fiber with priv == NULL triggers a kernel panic (crash).

An attacker with root or physical hardware access can cause a Denial-of-Service (DoS) condition.

Here’s a pseudo-exploit (not for actual use!)

# On a vulnerable system, rebooting with a custom device tree can crash it:
echo "your custom at8031 phy overlay" > /sys/firmware/fdt

# Or, in some systems, simply causing a network reset or unplugging/replugging cables triggers device probe:
ip link set eth down
ip link set eth up
# ...kernel panic may occur if the bug exists!

Upstream Linux Patch:

net: phy: qcom: at803x: fix kernel panic with at8031_probe

NVD CVE Entry:

CVE-2024-26942

Linux commits history:

git.kernel.org - at803x driver

How To Stay Safe

- Patch your kernel: Apply any update incorporating the fix (look for kernel versions released after mid-March 2024).
- If you cannot update, avoid plugging/unplugging affected hardware or exposing systems to untrusted users with hardware access.

Bottom Line

CVE-2024-26942 may not allow remote code execution, but it’s a solid Denial-of-Service (crash) risk for any system relying on the at803x PHY. Embedded device users, network admins, and distros should make sure to update to a safe Linux kernel version as soon as possible!


🛡️ *For more technical deep-dives on Linux kernel bugs, follow security mailing lists or your distribution’s security advisories!*

Timeline

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