A new vulnerability, CVE-2024-50084, was recently resolved in the Linux kernel. This issue specifically affects the Microchip VCAP (Versatile Content Addressable Processor) API within the kernel networking subsystem. The root cause was a set of memory leaks introduced by a previous patch intended to fix a use-after-free bug within the function vcap_api_encode_rule_test()― commonly used in kernel self-tests (KUnit).

In this article, we’ll explain in simple language what went wrong, how it was fixed, and how it could potentially be exploited if left unpatched. Read on for code snippets, deep-dive explanations, and links to original sources.

What is VCAP and Where is the Problem?

VCAP (Versatile Content Addressable Processor) is part of the Microchip (formerly Microsemi) Ethernet switch driver subsystem in Linux. It’s used to help match and act on network traffic inside the kernel, configured via programmable rules.

The bug appears in the self-test code (vcap_api_encode_rule_test()) of the VCAP API, where various rules are encoded and tested for proper function, using the KUnit test framework.

Initial Use-After-Free Fix:

A previous patch (commit a3c1e45156ad) fixed a severe use-after-free bug in this area.

New Bug Introduced:

While fixing the use-after-free, some critical calls to vcap_free_rule() were accidentally removed, which led to memory allocated in the tests never being freed.

Discovery:

Memory leak detectors (like kmemleak) started reporting unreferenced objects after running these tests.

What Does the Memory Leak Look Like?

When the test ran, it allocated several objects (such as rules, actions, or keys), but never freed them after use. This led to memory waste in the kernel—and with repeated runs, could potentially saturate kernel memory.

Here’s a typical kmemleak report

unreferenced object xffffff80ca58b700 (size 192):
  comm "kunit_try_catch", pid 1215, jiffies 4294898264
  backtrace (crc 9c09c3fe):
    [<...>] kmemleak_alloc+x34/x40
    [<...>] __kmalloc_cache_noprof+x26c/x2f4
    [<...>] vcap_alloc_rule+x3cc/x9c4
    [<...>] vcap_api_encode_rule_test+x1ac/x16b
    ...

Many more (64-byte and 192-byte allocations) leaked in a similar way.

The Vulnerable Code Path (Before the Fix)

The problem: after testing a rule, the test would just finish, and the rule’s memory would never be reclaimed.

Here’s a simplified pseudo-code snippet to illustrate the error

static void vcap_api_encode_rule_test(struct kunit *test)
{
    struct vcap_rule *rule = vcap_alloc_rule(...);
    if (!rule)
        return;
    // ... Set up test ...
    // ... Run test ...

    // Missing cleanup:
    // vcap_free_rule(rule); // <-- This line was missing!
}

Result:
Every time the test runs, memory allocated for rule and related objects is lost.

The Fix: Adding Back the Cleanups

The maintainers responded by restoring the missing calls to vcap_free_rule(), so each allocated rule (and related children) is properly freed when no longer needed.

Fixed code (short, illustrative)

static void vcap_api_encode_rule_test(struct kunit *test)
{
    struct vcap_rule *rule = vcap_alloc_rule(...);
    if (!rule)
        return;
    // ... Test logic ...

    vcap_free_rule(rule); // <-- Memory is now freed!
}

Commit:
You can see the patch in action in this commit diff (may be integrated differently depending on kernel tree).

A leaky test run exhausts kernel memory, leading to a DoS (Denial-of-Service) condition.

In this case, upstream maintainers decided to assign a CVE, showing the seriousness with which even “test-time” leaks are treated.

1. Local DoS:

- If an unprivileged user can somehow force the test suite to run continuously, kernel memory could be exhausted, crashing the system.

3. Wider Impact:

- In production kernels, test code is usually not run, and modules are not enabled, so the real-world exploitation risk is low. But, many Linux distros include self-test support in debug or custom builds.

How to Fix It

Upgrade your kernel!
The fix was merged into mainline and stable branches as of June 2024.

For reference, the fix appeared here:

- Linux kernel change log entry

References & Further Reading

- CVE-2024-50084 at CVE Details
- Fix commit in netdev/net-next tree
- Microchip VCAP API source (linux-kernel)
- Kmemleak (Linux Kernel Memory Leak Detector)
- Original patch discussion

Conclusion

CVE-2024-50084 illustrates why even test code memory leaks matter, especially in the kernel where leaky behavior can have outsized consequences. If you maintain, test, or backport kernel code for Microchip Ethernet devices, double-check your trees for this fix!

For most end-users, regular OS updates will already include this patch soon. But the lesson here is universal: *every alloc needs its free!*

Timeline

Published on: 10/29/2024 01:15:05 UTC
Last modified on: 10/30/2024 14:56:07 UTC