CVE Database
/

CVE-2024-56613

Back to search

CVE-2024-56613

Published: Dec 27, 2024

Modified: May 11, 2026

PUBLISHED

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/[email protected]/

VendorProductVersions

Linux

Linux

affected
ef6a22b70f6d90449a5c797b8968a682824e2011 - < 8f149bcc4d91ac92b32ff4949b291e6ed883dc42
affected
ef6a22b70f6d90449a5c797b8968a682824e2011 - < a71ddd5b87cda687efa28e049e85e923689bcef9
affected
ef6a22b70f6d90449a5c797b8968a682824e2011 - < 5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075

Linux

Linux

affected
6.4
unaffected
0 - < 6.4
unaffected
6.6.66 - <= 6.6.*
unaffected
6.12.5 - <= 6.12.*
unaffected
6.13 - <= *

Security Training

Train your team to recognize and prevent security threats with our comprehensive security awareness program.

Start Training

Vulnerability Scanning

Discover vulnerabilities in your applications and infrastructure before attackers do.

Scan Now