CVE-2024-50231 in Linux
Summary
by MITRE • 11/09/2024
In the Linux kernel, the following vulnerability has been resolved:
iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()
modprobe iio-test-gts and rmmod it, then the following memory leak occurs:
unreferenced object 0xffffff80c810be00 (size 64): comm "kunit_try_catch", pid 1654, jiffies 4294913981 hex dump (first 32 bytes): 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ backtrace (crc a63d875e): [] kmemleak_alloc+0x34/0x40
[] __kmalloc_noprof+0x2bc/0x3c0
[] devm_iio_init_iio_gts+0x4b4/0x16f4
[] 0xffffffdf052a62e0
[] 0xffffffdf052a6488
[] kunit_try_run_case+0x13c/0x3ac
[] kunit_generic_run_threadfn_adapter+0x80/0xec
[] kthread+0x2e8/0x374
[] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cbfe9e70 (size 16): comm "kunit_try_catch", pid 1658, jiffies 4294914015 hex dump (first 16 bytes): 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... backtrace (crc 857f0cb4): [] kmemleak_alloc+0x34/0x40
[] __kmalloc_noprof+0x2bc/0x3c0
[] devm_iio_init_iio_gts+0x4b4/0x16f4
[] 0xffffffdf052a62e0
[] 0xffffffdf052a6864
[] kunit_try_run_case+0x13c/0x3ac
[] kunit_generic_run_threadfn_adapter+0x80/0xec
[] kthread+0x2e8/0x374
[] ret_from_fork+0x10/0x20
......
It includes 5*5 times "size 64" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times "size 16" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5.
The reason is that the per_time_gains[i] is not freed which is allocated in
the "gts->num_itime" for loop in iio_gts_build_avail_scale_table().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/02/2025
The vulnerability CVE-2024-50231 represents a memory leak issue within the Linux kernel's industrial I/O (IIO) subsystem, specifically in the gts-helper module responsible for handling gain and integration time scaling tables. This flaw manifests during the execution of kernel unit tests involving the iio-test-gts module, where the memory management functions fail to properly release allocated memory blocks. The vulnerability occurs when the modprobe and rmmod commands are executed in sequence, triggering a series of memory allocation and deallocation operations that result in unreferenced memory objects remaining in the kernel's memory space.
The technical root cause of this memory leak stems from improper memory deallocation within the iio_gts_build_avail_scale_table() function, particularly in the context of the per_time_gains[i] array elements that are allocated during the processing of the gts->num_itime loop. During kernel unit testing scenarios, the function allocates memory for various scaling table components including gain and integration time arrays, but fails to release the per_time_gains[i] memory blocks that were dynamically allocated within the loop structure. This memory management oversight creates a persistent leak where multiple 64-byte and 16-byte memory objects accumulate in the kernel's memory pool, with the 64-byte allocations occurring 25 times corresponding to test scenarios involving gts_test_gains size 10 and gts_test_itimes size 5, while the 16-byte allocations occur 5 times with specific test configurations.
The operational impact of this vulnerability extends beyond simple memory consumption issues, as it represents a potential denial of service vector that could gradually exhaust kernel memory resources, particularly in systems running continuous IIO operations or those subjected to frequent kernel module loading and unloading cycles. The memory leak pattern indicates that this vulnerability is specifically triggered during automated testing scenarios, suggesting that it may be more prevalent in development environments or systems where kernel unit tests are regularly executed. From a cybersecurity perspective, this vulnerability aligns with CWE-401: Improper Release of Memory and could potentially be exploited by malicious actors to perform resource exhaustion attacks against kernel subsystems. The vulnerability also demonstrates characteristics consistent with ATT&CK technique T1490: Inhibit System Recovery, as memory leaks can contribute to system instability and reduced performance over time, particularly in embedded systems or devices where memory resources are constrained.
Mitigation strategies for CVE-2024-50231 should focus on implementing proper memory management within the affected kernel module, ensuring that all dynamically allocated memory blocks are correctly freed before function exit or module unloading. System administrators should prioritize applying the patched kernel version that resolves this memory leak issue, particularly in production environments where the iio-test-gts module may be actively used. Additionally, monitoring systems should be implemented to track memory usage patterns and identify potential memory leak accumulation, while regular kernel updates should be maintained to address similar vulnerabilities in the broader IIO subsystem. The fix should include comprehensive testing of memory allocation and deallocation paths within the gts-helper module to prevent similar issues from occurring in other related functions, ensuring that all allocated memory within loop structures is properly released to maintain system stability and prevent resource exhaustion attacks.