CVE-2024-56613

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/numa: fix memory leak due to the overwritten vma-&gt;numab_state<br /> <br /> [Problem Description]<br /> When running the hackbench program of LTP, the following memory leak is<br /> reported by kmemleak.<br /> <br /> # /opt/ltp/testcases/bin/hackbench 20 thread 1000<br /> Running with 20*40 (== 800) tasks.<br /> <br /> # dmesg | grep kmemleak<br /> ...<br /> kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> <br /> # cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xffff888cd8ca2c40 (size 64):<br /> comm "hackbench", pid 17142, jiffies 4299780315<br /> hex dump (first 32 bytes):<br /> ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I.....<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc bff18fd4):<br /> [] __kmalloc_cache_noprof+0x2f9/0x3f0<br /> [] task_numa_work+0x725/0xa00<br /> [] task_work_run+0x58/0x90<br /> [] syscall_exit_to_user_mode+0x1c8/0x1e0<br /> [] do_syscall_64+0x85/0x150<br /> [] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> <br /> This issue can be consistently reproduced on three different servers:<br /> * a 448-core server<br /> * a 256-core server<br /> * a 192-core server<br /> <br /> [Root Cause]<br /> Since multiple threads are created by the hackbench program (along with<br /> the command argument &amp;#39;thread&amp;#39;), a shared vma might be accessed by two or<br /> more cores simultaneously. When two or more cores observe that<br /> vma-&gt;numab_state is NULL at the same time, vma-&gt;numab_state will be<br /> overwritten.<br /> <br /> Although current code ensures that only one thread scans the VMAs in a<br /> single &amp;#39;numa_scan_period&amp;#39;, there might be a chance for another thread<br /> to enter in the next &amp;#39;numa_scan_period&amp;#39; while we have not gotten till<br /> numab_state allocation [1].<br /> <br /> Note that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000`<br /> cannot the reproduce the issue. It is verified with 200+ test runs.<br /> <br /> [Solution]<br /> Use the cmpxchg atomic operation to ensure that only one thread executes<br /> the vma-&gt;numab_state assignment.<br /> <br /> [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/