CVE-2024-50254

In the Linux kernel, the following vulnerability has been resolved:

bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()

bpf_iter_bits_destroy() uses kit->nr_bits <= 64 to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below:

unreferenced object 0xffff88812628c8c0 (size 32): comm swapper/0, pid 1, jiffies 4294727320 hex dump (first 32 bytes): b0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U……….. f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 ………….. backtrace (crc 781e32cc): [<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 [<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 [<00000000597124d6>] __alloc.isra.0+0x89/0xb0 [<000000004ebfffcd>] alloc_bulk+0x2af/0x720 [<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 [<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 [<000000008b616eac>] bpf_global_ma_init+0x19/0x30 [<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 [<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 [<00000000b119f72f>] kernel_init+0x20/0x160 [<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 [<0000000004671da4>] ret_from_fork_asm+0x1a/0x30

That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated.

Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use !nr_bits || bits >= nr_bits to check whether the iteration is complete and still use nr_bits > 64 to indicate whether bits are dynamically allocated. The !nr_bits check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits.

Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.

Weakness

The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

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/101ccfbabf4738041273ce64e2b116cf440dea13
• https://git.kernel.org/stable/c/9cee266fafaf79fd465314546f637f9a3c215830