CVE-2024-50231

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):
    [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40
    [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0
    [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4
    [<0000000071bb4b09>] 0xffffffdf052a62e0
    [<000000000315bc18>] 0xffffffdf052a6488
    [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac
    [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec
    [<00000000f505065d>] kthread+0x2e8/0x374
    [<00000000bbfb0e5d>] 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):
    [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40
    [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0
    [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4
    [<0000000071bb4b09>] 0xffffffdf052a62e0
    [<000000007d089d45>] 0xffffffdf052a6864
    [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac
    [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec
    [<00000000f505065d>] kthread+0x2e8/0x374
    [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20
......

It includes 55 times size 64 memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10size(int)) and gts_test_itimes size 5. It also includes 51 times size 16 memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3size(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().

Weakness

The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.

Affected Software

Potential Mitigations

• Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
• For example, glibc in Linux provides protection against free of invalid pointers.
• When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
• To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

References

• https://git.kernel.org/stable/c/16e41593825c3044efca0eb34b2d6ffba306e4ec
• https://git.kernel.org/stable/c/38d6e8be234d87b0eedca50309e25051888b39d1
• https://git.kernel.org/stable/c/691e79ffc42154a9c91dc3b7e96a307037b4be74