CVE-2024-50084 in Linux
Summary
by MITRE • 10/29/2024
In the Linux kernel, the following vulnerability has been resolved:
net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()
Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in kunit test") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it.
unreferenced object 0xffffff80ca58b700 (size 192): comm "kunit_try_catch", pid 1215, jiffies 4294898264 hex dump (first 32 bytes): 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ backtrace (crc 9c09c3fe): [] kmemleak_alloc+0x34/0x40
[] __kmalloc_cache_noprof+0x26c/0x2f4
[] vcap_alloc_rule+0x3cc/0x9c4
[] vcap_api_encode_rule_test+0x1ac/0x16b0
[] kunit_try_run_case+0x13c/0x3ac
[] kunit_generic_run_threadfn_adapter+0x80/0xec
[] kthread+0x2e8/0x374
[] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0400 (size 64): comm "kunit_try_catch", pid 1215, jiffies 4294898265 hex dump (first 32 bytes): 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... backtrace (crc daf014e9): [] kmemleak_alloc+0x34/0x40
[] __kmalloc_cache_noprof+0x26c/0x2f4
[] vcap_rule_add_key+0x2cc/0x528
[] vcap_api_encode_rule_test+0x224/0x16b0
[] kunit_try_run_case+0x13c/0x3ac
[] kunit_generic_run_threadfn_adapter+0x80/0xec
[] kthread+0x2e8/0x374
[] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0700 (size 64): comm "kunit_try_catch", pid 1215, jiffies 4294898265 hex dump (first 32 bytes): 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... backtrace (crc 8d877792): [] kmemleak_alloc+0x34/0x40
[] __kmalloc_cache_noprof+0x26c/0x2f4
[] vcap_rule_add_action+0x2d0/0x52c
[] vcap_api_encode_rule_test+0x4d4/0x16b0
[] kunit_try_run_case+0x13c/0x3ac
[] kunit_generic_run_threadfn_adapter+0x80/0xec
[] kthread+0x2e8/0x374
[] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0900 (size 64): comm "kunit_try_catch", pid 1215, jiffies 4294898266 hex dump (first 32 bytes): 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... backtrace (crc 34181e56): [] kmemleak_alloc+0x34/0x40
[] __kmalloc_cache_noprof+0x26c/0x2f4
[] vcap_rule_add_key+0x2cc/0x528
[] vcap_val_rule+0xcf0/0x13e8
[] vcap_api_encode_rule_test+0x678/0x16b0
[] kunit_try_run_case+0x13c/0x3ac
[] kunit_generic_run_threadfn_adapter+0x80/0xec
[] kthread+0x2e8/0x374
[] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0980 (size 64): comm "kunit_try_catch", pid 1215, jiffies 4294898266 hex dump (first 32 bytes): 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... backtrace (crc 275fd9be): [] kmemleak_alloc+0x34/0x40
[] __kmalloc_cache_noprof+0x26c/0x2f4
[] vcap_rule_add_key+0x2cc/0x528
[] test_add_de
---truncated---
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2025
The vulnerability identified as CVE-2024-50084 resides within the Linux kernel's networking subsystem, specifically in the Microchip VCAP (Virtual Content Addressable Memory) API implementation. This issue manifests as memory leaks occurring during the execution of kernel unit tests, particularly within the `vcap_api_encode_rule_test()` function. The root cause stems from a previous fix for a use-after-free error in commit a3c1e45156ad, which inadvertently introduced these memory leaks by omitting the necessary cleanup call to `vcap_free_rule()`. The vulnerability is classified under CWE-401, which denotes "Improper Release of Memory" and aligns with ATT&CK technique T1059.008, indicating potential exploitation through kernel memory corruption pathways.
The technical flaw manifests as unreferenced kernel memory objects that persist in memory after the completion of test execution, leading to gradual resource exhaustion. The memory leak analysis shows multiple instances of allocated memory blocks, each with distinct sizes and backtrace patterns indicating their allocation within the VCAP rule management functions. The first object of 192 bytes originates from `vcap_alloc_rule()` and is traced back to `vcap_api_encode_rule_test()`, while subsequent allocations of 64 bytes are traced through `vcap_rule_add_key()` and `vcap_rule_add_action()` functions. These allocations occur in a test environment where kernel memory is not properly released, creating a persistent memory footprint that could degrade system performance or enable resource exhaustion attacks.
The operational impact of this vulnerability is primarily observed in kernel testing environments, where repeated test execution can lead to progressive memory consumption. While the leak does not directly expose the system to external exploitation, it represents a degradation in system stability and resource management. The vulnerability is particularly concerning in embedded systems or environments where memory resources are constrained, as the accumulation of leaked memory can lead to system instability or unexpected behavior. The presence of these memory leaks in unit test code also indicates a potential for similar issues in production code paths, especially if similar patterns exist elsewhere in the VCAP API implementation. This vulnerability could be leveraged by adversaries to perform resource exhaustion attacks, potentially leading to denial of service conditions.
Mitigation strategies should focus on ensuring proper memory management within the VCAP API functions, particularly in test cases and production code paths. The immediate fix involves reintroducing the `vcap_free_rule()` call that was inadvertently removed during the previous fix for the use-after-free vulnerability. System administrators should apply the relevant kernel patches that address this specific memory leak issue. Additionally, comprehensive code reviews should be conducted to identify and address similar memory management issues in other VCAP API functions. The implementation of memory leak detection tools and regular kernel memory audits can help prevent similar issues from arising in future releases. Organizations should also consider implementing automated testing that includes memory leak detection mechanisms to catch such issues during development and integration phases.