CVE-2024-56613
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2024-56613
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-56613.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2024-56613
- Downstream
- Related
- Published
- 2024-12-27T14:51:18Z
- Modified
- 2025-10-17T19:09:24.226730Z
- Severity
-
- 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
- Summary
- sched/numa: fix memory leak due to the overwritten vma->numab_state
- Details
-
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): [<ffffffff81419a89>] _kmalloccachenoprof+0x2f9/0x3f0 [<ffffffff8113f715>] tasknumawork+0x725/0xa00 [<ffffffff8110f878>] taskworkrun+0x58/0x90 [<ffffffff81ddd9f8>] syscallexittousermode+0x1c8/0x1e0 [<ffffffff81dd78d5>] dosyscall64+0x85/0x150 [<ffffffff81e0012b>] entrySYSCALL64after_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->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 numab_state allocation [1].
Note that the command
/opt/ltp/testcases/bin/hackbench 50 process 1000cannot 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/
- References
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedef6a22b70f6d90449a5c797b8968a682824e2011Fixed8f149bcc4d91ac92b32ff4949b291e6ed883dc42
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedef6a22b70f6d90449a5c797b8968a682824e2011Fixeda71ddd5b87cda687efa28e049e85e923689bcef9
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedef6a22b70f6d90449a5c797b8968a682824e2011Fixed5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075