CVE-2024-26653 - Double Free Vulnerability Fixed in Linux Kernel USB ljca Device Driver

- CVE-2024-26653 Details
- Linux Kernel Patch Commit

What is CVE-2024-26653?

CVE-2024-26653 is a security vulnerability found in the Linux kernel's usb: misc: ljca driver. The bug was about a "double free" scenario when cleaning up after an error. That means, under some error circumstances, the kernel tried to free the same chunk of memory twice — which can lead to kernel crashes, memory corruption, privilege escalation, or in some special cases, potential code execution.

Technical Background

The ljca driver in the Linux kernel handles certain USB hardware. It uses auxiliary devices for handling these functions. Suppose something goes wrong while initializing a device using auxiliary_device_add(). In such a case, cleanup is necessary, which is where the bug lived.

Here's what happened

- If adding the device (auxiliary_device_add()) failed, a cleanup function (auxiliary_device_uninit()) runs.
- This cleanup calls another function (ljca_auxdev_release), which then calls kfree() on memory pointed to by platform_data.
- The caller of the initialization routine would, on error, also call kfree() on platform_data, not realizing it was already freed.

Hence: double free.

Double frees are hard to hit sometimes, but they are dangerous, and in the kernel can sometimes be exploited by attackers with local access to cause system instability or even run code as root.

Here's a pseudo-simplified flow of the vulnerable code

struct platform_data *pdata = kmalloc(sizeof(*pdata), GFP_KERNEL);
int ret = ljca_new_client_device(pdata);
if (ret) {
    kfree(pdata);   // <-- BAD: Already freed in error path inside ljca_new_client_device!
    return ret;
}

Inside ljca_new_client_device() (simplified)

if (auxiliary_device_add(&auxdev->dev)) {
    auxiliary_device_uninit(&auxdev->dev); // Calls ljca_auxdev_release
    // ... ljca_auxdev_release calls kfree(auxdev->dev.platform_data)
    return error;
}
// On success, auxdev->dev.platform_data is managed elsewhere

So both the caller and the driver tried to free the same thing. That’s a classic double free bug.

Callers no longer kfree() the platform data pointer after errors.

- The ljca_new_client_device and related code now free platform_data in only one spot if initial setup fails before device creation.
- This ensures double free can't happen—memory is cleaned up once, at the correct point in the error-handling flow.

Here's an excerpt of the fixed code logic

struct platform_data *pdata = kmalloc(sizeof(*pdata), GFP_KERNEL);
int ret = ljca_new_client_device(pdata);
if (ret) {
    // No kfree() needed! Already handled inside ljca_new_client_device().
    return ret;
}

Exploitation Details

Attack surface:
A local attacker with permissions to plug/unplug USB devices or otherwise interact with the ljca device node could potentially exploit this. The bar is relatively high: the attacker must trigger an allocation and then an error, causing the double free. Carefully crafted memory layouts may, in rare cases, allow further exploitation (typically, reliability is low due to kernel hardening, but possible on unprotected systems).

Impact:
In most cases, it’d cause a kernel panic (system crash) rather than remote code execution. However, double free is a known category for privilege escalation attempts, especially if an attacker can manipulate memory allocations nearby in the kernel heap.

Update your kernel!

Distributions have already backported the fix to supported versions. Check your package manager for kernel updates.

Verify with your vendor:

Red Hat, Ubuntu, SUSE, and others have assigned this CVE and released advisories as patches are ready.

Extra Hardening:

If you cannot update quickly, consider blacklisting the ljca driver as a temporary mitigation (rarely used unless you have the specific matching hardware).

Learn More

- Patch Commit in Kernel
- CVE-2024-26653 on MITRE
- Linux Security Mailing List Archive

Final Thoughts

While this bug is not a headline-grabbing remote attack, it’s a strong example of why careful error handling in the kernel matters. Memory management mistakes like double free can have serious consequences — so keep your systems patched, and remember: always free memory once, and only once!

If you work on kernel code, remember to double-check — and if in doubt, review recent fixes for inspiration!

Timeline

Published on: 04/01/2024 09:15:51 UTC
Last modified on: 01/14/2025 15:37:45 UTC