CVE-2024-56613: sched/numa: fix memory leak due to the overwritten vma->numab_state
In the Linux kernel, the following vulnerability has been resolved:
sched/numa: fix memory leak due to the overwritten vma->numabstate
[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 2040 (== 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): [<ffffffff81419a89>] kmalloccachenoprof+0x2f9/0x3f0 [<ffffffff8113f715>] tasknumawork+0x725/0xa00 [<ffffffff8110f878>] taskworkrun+0x58/0x90 [<ffffffff81ddd9f8>] syscallexittousermode+0x1c8/0x1e0 [<ffffffff81dd78d5>] dosyscall64+0x85/0x150 [<ffffffff81e0012b>] entrySYSCALL64afterhwframe+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->numabstate is NULL at the same time, vma->numabstate will be overwritten.
Although current code ensures that only one thread scans the VMAs in a single 'numascanperiod', there might be a chance for another thread to enter in the next 'numascanperiod' while we have not gotten till numabstate 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->numabstate assignment.
[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/
Other sources
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2024-56613?
CVE-2024-56613 is considered a moderate severity vulnerability due to the possibility of memory leaks.
How do I fix CVE-2024-56613?
To fix CVE-2024-56613, update your Linux kernel to a version that includes the patch for this vulnerability.
Which Linux kernel versions are affected by CVE-2024-56613?
CVE-2024-56613 affects Linux kernel versions between 6.4 and 6.6.66, as well as versions between 6.7 and 6.12.5.
What type of vulnerability is CVE-2024-56613?
CVE-2024-56613 is a memory leak vulnerability found in the Linux kernel.
Is CVE-2024-56613 present in earlier versions of the Linux kernel?
CVE-2024-56613 is not reported to be present in earlier versions prior to 6.4.