CVE-2024-56613

Modified
Published: 27 Dec 2024, 14:51
Last modified:11 May 2026, 20:55

Vulnerability Summary

Overall Risk (default)
low
22/100
CVSS Score
5.5 MEDIUM
v3.1 (cve.org)
EPSS Score
0.02% LOW
0% probability -0.01%
KEV
Not listed
Ransomware
No reports
Public exploits
None found
Dark Web
Not detected

Timeline

27 Dec 2024, 14:51
Published
Vulnerability first disclosed
11 May 2026, 20:55
Last Modified
Vulnerability information updated

Description

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>] __kmalloc_cache_noprof+0x2f9/0x3f0 [<ffffffff8113f715>] task_numa_work+0x725/0xa00 [<ffffffff8110f878>] task_work_run+0x58/0x90 [<ffffffff81ddd9f8>] syscall_exit_to_user_mode+0x1c8/0x1e0 [<ffffffff81dd78d5>] do_syscall_64+0x85/0x150 [<ffffffff81e0012b>] 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/

CVSS Metrics

  • v3.1MEDIUMScore: 5.5CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

EPSS Trends

Current EPSS score: 0.02% Percentile: 4%

Techniques & Countermeasures

  • CWE-401Missing Release of Memory after Effective Lifetime

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

Affected Systems

  • linuxlinux

    ≥ ef6a22b70f6d90449a5c797b8968a682824e2011, < 8f149bcc4d91ac92b32ff4949b291e6ed883dc42 | ≥ ef6a22b70f6d90449a5c797b8968a682824e2011, < a71ddd5b87cda687efa28e049e85e923689bcef9 | ≥ ef6a22b70f6d90449a5c797b8968a682824e2011, < 5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075 | 6.4

  • linuxlinux_kernel

    ≥ 6.4, < 6.6.66 | ≥ 6.7, < 6.12.5 | 6.13:rc1

References (3)