### [CVE-2024-56613](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56613)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=ef6a22b70f6d90449a5c797b8968a682824e2011%3C%208f149bcc4d91ac92b32ff4949b291e6ed883dc42%20&color=brighgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### 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 isreported 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 withthe command argument 'thread'), a shared vma might be accessed by two ormore cores simultaneously. When two or more cores observe thatvma->numab_state is NULL at the same time, vma->numab_state will beoverwritten.Although current code ensures that only one thread scans the VMAs in asingle 'numa_scan_period', there might be a chance for another threadto enter in the next 'numa_scan_period' while we have not gotten tillnumab_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 executesthe vma->numab_state assignment.[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/cku-heise/euvd-api-doc