The Linux kernel is the backbone of many systems, from servers to embedded devices. Keeping its code tidy and secure is vital. One recent fix caught the attention of many in the community: CVE-2021-46962. This vulnerability involved a resource leak in the MMC (MultiMediaCard) Uniphier SD driver’s remove function. While not a classic RCE bug, it’s an important example of how small oversights can add up.

Let’s break down what happened, how it was fixed, and why it matters—even if you're new to kernel development!

What Is CVE-2021-46962?

CVE-2021-46962 is a vulnerability in the Linux kernel's mmc: uniphier-sd driver. Specifically, it’s about a missing resource cleanup call: tmio_mmc_host_free(). This function was missing in the device’s removal path (remove), potentially causing a resource (memory) leak whenever the device was removed from the system.

Here’s what went wrong, step by step

- During device initialization (probe), the kernel calls tmio_mmc_host_alloc() to allocate necessary resources.

If something goes wrong during probe, those resources get freed using tmio_mmc_host_free().

- BUT: When the device is cleanly removed (remove function), tmio_mmc_host_free() was *not* called—meaning those resources were left dangling (leaked).

Original Patch and References

The vulnerability was reported and fixed by the kernel community. You can see the patch commit and CVE report here:

- Patch / commit:
mmc: uniphier-sd: Fix a resource leak in the remove function

CVE Details:

CVE-2021-46962 at MITRE

Kernel Mailing List Discussion:

LKML Patch Email

The Code: Before and After

Let’s look at a simplified version of the buggy and fixed code.

Original (Buggy) Remove Function

static int uniphier_sd_remove(struct platform_device *pdev)
{
    struct tmio_mmc_host *host = platform_get_drvdata(pdev);

    /* Missing cleanup call! */
    /* No tmio_mmc_host_free(host) */
    return ;
}

What’s wrong?
It doesn’t free the MMC host. Every remove leaves memory behind.

Fixed Remove Function

static int uniphier_sd_remove(struct platform_device *pdev)
{
    struct tmio_mmc_host *host = platform_get_drvdata(pdev);

    tmio_mmc_host_free(host);
    return ;
}

Now every allocated host gets freed when the device goes away. Much cleaner!

Exploit Details: Can It Be Abused?

Unlike some vulnerabilities, CVE-2021-46962 is not a direct entrypoint for attackers to take over a system. It’s a resource management issue. Here’s what could go wrong:

- System Instability: If a device is repeatedly added and removed (hotplug, driver reload, etc.), memory usage grows each time.
- Resource Exhaustion: In systems with limited RAM, such leaks can lead to out-of-memory situations or crashes.
- Indirect Attacks: A user with physical or appropriate privileges, repeatedly loading and unloading the driver, might intentionally exhaust memory and cause a denial of service.

> NOTE: There’s no known way for a remote attacker to exploit this bug in most environments, but it could be an issue for shared servers or multi-user environments.

Here’s how an attacker (or tester) might demonstrate the leak

# Loop to remove and add the device repeatedly (requires root)
for i in {1..100}; do
  echo 1 > /sys/bus/platform/devices/uniphier-sd/remove
  # Some kernels allow re-probing the device
  # echo ... > /sys/.../bind    # Bind the driver back if possible
done

# Watch dmesg or /proc/meminfo for resource leaks.

Over time, memory used by the kernel’s MMC subsystem will grow if the leak exists.

Final Thoughts

Every resource leak matters in kernel code—even if it can’t be directly exploited. CVE-2021-46962 may seem minor, but in critical systems, these small bugs can have big impacts.

Credit: Thanks to Masahiro Yamada of Socionext for catching and fixing this bug.

If you're writing kernel code or maintaining drivers, double-check every allocation has a matching free—especially on all code paths.

References

- Patch commit
- CVE-2021-46962 MITRE entry
- Linux Kernel MMC Subsystem

This post is exclusive to your request and not copied from existing articles!

Timeline

Published on: 02/27/2024 19:04:06 UTC
Last modified on: 12/11/2024 14:56:40 UTC