CVE-2024-35796 - Deep Dive into the Linux Kernel ll

A new vulnerability, CVE-2024-35796, was identified and resolved in the Linux kernel's Xilinx TEMAC Ethernet MAC (ll_temac) driver. While this bug revolves around a subtle mistake in resource management code, it leads to a scenario where a NULL pointer dereference could crash the kernel—a significant stability and security risk in embedded or networked Linux systems.

In this long read, we’ll break down the cause of CVE-2024-35796, how the code works (with snippets), why the bug happens, what the fix is, and how to stay protected. We keep language simple and fluff-free.

Vulnerability High-Level Overview

- Component: Linux kernel, drivers/net/ethernet/xilinx/ll_temac_main.c
- Issue: Replacing platform_get_resource() with devm_platform_ioremap_resource_byname() called with the wrong argument (passing as a resource name).

Impact: Leads to a NULL pointer dereference, which can crash the kernel if triggered.

- Resolution: Use devm_platform_ioremap_resource() (without the "_byname" part) instead, which just uses the integer index, not a resource name.

Before the Bug: The Old Code

Traditionally, resources in platform drivers are fetched by either an index or a name. platform_get_resource() can take an index. Here’s what typical, correct code looks like:

res = platform_get_resource(pdev, IORESOURCE_MEM, );
base = devm_ioremap_resource(&pdev->dev, res);

A patch tried to streamline code by using new helpers. The developer swapped this logic

base = devm_ioremap_resource(&pdev->dev,
       platform_get_resource(pdev, IORESOURCE_MEM, ));

with this

base = devm_platform_ioremap_resource_byname(pdev, );

- Deep in the call stack, the following code is executed

if (type == resource_type(r) && !strcmp(r->name, name))

If name is NULL (from ), strcmp will crash (segfault), since it can't compare with NULL.

Proof: The Crash Path

- User triggers probe of ll_temac driver (say, by loading a device or booting a board using this Ethernet).

Exploiting CVE-2024-35796

This bug is not a direct privilege escalation or "remote code execution" flaw, but it is a clear denial-of-service vector.

Real-world exploit scenario

- An attacker with control over the device tree (DT) or platform data could cause the driver to get probed.
- Alternatively, just booting a board with the vulnerable kernel and a Xilinx TEMAC device triggers the bug.

Use devm_platform_ioremap_resource()

base = devm_platform_ioremap_resource(pdev, );

This version just takes a resource index and is safe.

Bad code (the buggy way)

base = devm_platform_ioremap_resource_byname(pdev, ); // WRONG

Good code (the fix)

base = devm_platform_ioremap_resource(pdev, ); // RIGHT

Commit Reference

You can see the fix in the Linux kernel git tree:
- Upstream commit: net: ll_temac: fix crash on probe by using correct resource function

Source for CVE

- CVE-2024-35796 on cve.org

Is there a remote exploit?

- No. This is a denial-of-service bug that can be triggered by booting affected hardware or crafting device tree blobs.

Summary

With CVE-2024-35796, we see how even small mistakes in resource handling in kernel code can have big stability impacts. This bug is now fixed upstream. If your Linux systems use the Xilinx ll_temac driver, patch your kernel ASAP to avoid unexpected kernel panics or system crashes.

*Keep your systems up-to-date, review code changes carefully, and understand how kernel API changes can introduce subtle but dangerous bugs.*

Timeline

Published on: 05/17/2024 14:15:11 UTC
Last modified on: 10/29/2024 20:35:21 UTC

CVE-2024-35796 - Deep Dive into the Linux Kernel ll_temac Bug and Its Fix