The Linux kernel is the lifeblood of countless devices, from servers to everyday routers. Reliability and security in its codebase are paramount. A recent vulnerability, CVE-2024-46856, showed just how a small oversight can cause big problems—even a system crash. Here’s an exclusive deep dive, with code, technical breakdown, and what you need to know.

What Is CVE-2024-46856?

CVE-2024-46856 exists in the Linux kernel’s handling of certain Ethernet PHY devices—specifically the Texas Instruments DP83825, DP83822, and DP83826 chips.

In simple terms:
Due to a coding error, the driver for DP83825 didn't initialize specific data pointers, leading to a possible NULL pointer dereference. Accessing such a NULL pointer can instantly crash the Linux kernel—potentially causing denial of service or, more rarely, be manipulated for further exploitation.

Where Was the Bug?

The bug was hiding in code handling network hardware in the file:
drivers/net/phy/dp83822.c

The original *probe* function (setup code for the hardware) only worked correctly for DP83822 and DP83826 chips. The closely related DP83825 was left out, so a critical *private data pointer* was left NULL. Later code assumed the pointer was valid—for DP8382x hardware in general—and would crash when accessing it for DP83825 chips.

Here’s a simplified snippet of the problem

static int dp83822_probe(struct phy_device *phydev)
{
    struct dp83822_private *dp83822;

    // Only allocates for DP83822 and DP83826, NOT DP83825!
    if (phydev->driver->phy_id == DP83822_PHY_ID ||
        phydev->driver->phy_id == DP83826_PHY_ID) {
        dp83822 = devm_kzalloc(&phydev->mdio.dev, sizeof(*dp83822), GFP_KERNEL);
        phydev->priv = dp83822;
    }

    // ...rest of setup...
}

// Later, in config_init or set_wol:
struct dp83822_private *dp = phydev->priv;  // This may be NULL for DP83825!
// ... kernel crash if dp used ...

The bug: For DP83825 devices, phydev->priv wasn’t set. If any code tried to access fields through that pointer, it would dereference NULL and crash the kernel.

How Was It Fixed?

Solution:
The patch introduces a common probe function, dp8382x_probe(), used for all three chip models (DP83822, DP83825, DP83826). Now, all have their private data correctly allocated, stopping the NULL pointer dereference from happening.

Patch Example

static int dp8382x_probe(struct phy_device *phydev)
{
    struct dp83822_private *dp83822;
    dp83822 = devm_kzalloc(&phydev->mdio.dev, sizeof(*dp83822), GFP_KERNEL);
    if (!dp83822)
        return -ENOMEM;
    phydev->priv = dp83822;
    return ;
}

Then, each driver entry uses this probe function, ensuring safety for all models.

Kernel versions with the original (buggy) DP83822 driver changes.

If a system used the buggy driver and exercised code that relied on the missing pointer (like setting network parameters, Wake-on-LAN, or just probing the device), the kernel could panic and crash.

Exploit Details

Impact:

This is mainly a *denial of service* bug.

- A local, unprivileged user would need to trigger the affected code paths, which usually requires physical access to the hardware or root-level manipulation of network hardware settings.

Proof of Concept:
While a remote attack is highly unlikely, a crafted tool or command running with sufficient privilege, targeting network interface settings, could trigger the crash whenever the affected DP83825 chip is present.

# Example: forcing hardware re-probe (simulate by ifconfig or ethtool cycles)
ifconfig eth down
ifconfig eth up
# or use: ethtool -s eth wol g
# On a system with vulnerable kernel & DP83825, could crash!

- Upstream Patch: net: phy: dp83822: Fix NULL pointer dereference on DP83825 devices (commit)

Kernel Mailing List (original submission):

https://lore.kernel.org/netdev/20240603123521.1702249-1-m.tretter@pengutronix.de/

Linux distributions are already updating affected kernels, and new releases include the fix.

Conclusion

CVE-2024-46856 is a classic example of how a seemingly minor oversight—missing an init step for a hardware variant—can bring down an entire system. With the fix, all DP8382x chips are equally protected. If you use or manage Linux devices with TI Ethernet PHY hardware, it’s time to patch!

References

- Patch Commit on kernel.org
- Linux Kernel Mailing List Post
- NVD Entry for CVE-2024-46856 (when available) (May take time to update)

Timeline

Published on: 09/27/2024 13:15:17 UTC
Last modified on: 10/01/2024 16:04:54 UTC