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

sched/numa: fix memory leak due to the overwritten vma->numab_state

[Problem Description] When running the hackbench program of LTP, the following memory leak is reported by kmemleak.

/opt/ltp/testcases/bin/hackbench 20 thread 1000

Running with 20*40 (== 800) tasks.

dmesg | grep kmemleak

… kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

cat /sys/kernel/debug/kmemleak

unreferenced object 0xffff888cd8ca2c40 (size 64): comm hackbench, pid 17142, jiffies 4299780315 hex dump (first 32 bytes): ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI…..L.I….. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace (crc bff18fd4): [] __kmalloc_cache_noprof+0x2f9/0x3f0 [] task_numa_work+0x725/0xa00 [] task_work_run+0x58/0x90 [] syscall_exit_to_user_mode+0x1c8/0x1e0 [] do_syscall_64+0x85/0x150 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e …

This issue can be consistently reproduced on three different servers:

• a 448-core server
• a 256-core server
• a 192-core server

[Root Cause] Since multiple threads are created by the hackbench program (along with the command argument thread), a shared vma might be accessed by two or more cores simultaneously. When two or more cores observe that vma->numab_state is NULL at the same time, vma->numab_state will be overwritten.

Although current code ensures that only one thread scans the VMAs in a single numa_scan_period, there might be a chance for another thread to enter in the next numa_scan_period while we have not gotten till numab_state allocation [1].

Note that the command /opt/ltp/testcases/bin/hackbench 50 process 1000 cannot the reproduce the issue. It is verified with 200+ test runs.

[Solution] Use the cmpxchg atomic operation to ensure that only one thread executes the vma->numab_state assignment.

[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/

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/5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075
• https://git.kernel.org/stable/c/8f149bcc4d91ac92b32ff4949b291e6ed883dc42
• https://git.kernel.org/stable/c/a71ddd5b87cda687efa28e049e85e923689bcef9