UBUNTU-CVE-2024-56613
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]/
02 / AFFECTED SOFTWARE
Affected packages
16 explicit affected versions
2 explicit affected versions
14 explicit affected versions
29 explicit affected versions
10 explicit affected versions
11 explicit affected versions
15 explicit affected versions
9 explicit affected versions
1 explicit affected versions
2 explicit affected versions
18 explicit affected versions
7 explicit affected versions
26 explicit affected versions
37 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
13 explicit affected versions
17 explicit affected versions
11 explicit affected versions
78 explicit affected versions
45 explicit affected versions
37 explicit affected versions
8 explicit affected versions
4 explicit affected versions
8 explicit affected versions
19 explicit affected versions
23 explicit affected versions
7 explicit affected versions
14 explicit affected versions
10 explicit affected versions
16 explicit affected versions
33 explicit affected versions
16 explicit affected versions
13 explicit affected versions
2 explicit affected versions
12 explicit affected versions
38 explicit affected versions
1 explicit affected versions
51 explicit affected versions
13 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
1 explicit affected versions
1 explicit affected versions
10 explicit affected versions
10 explicit affected versions
1 explicit affected versions
20 explicit affected versions
8 explicit affected versions
1 explicit affected versions
13 explicit affected versions
21 explicit affected versions
6 explicit affected versions
13 explicit affected versions
12 explicit affected versions
20 explicit affected versions
7 explicit affected versions
14 explicit affected versions
20 explicit affected versions
12 explicit affected versions
26 explicit affected versions
1 explicit affected versions
16 explicit affected versions
23 explicit affected versions
13 explicit affected versions
14 explicit affected versions
5 explicit affected versions
3 explicit affected versions
23 explicit affected versions
26 explicit affected versions
21 explicit affected versions
12 explicit affected versions
44 explicit affected versions
21 explicit affected versions
4 explicit affected versions
4 explicit affected versions
22 explicit affected versions
16 explicit affected versions
9 explicit affected versions
12 explicit affected versions
7 explicit affected versions
19 explicit affected versions
13 explicit affected versions
26 explicit affected versions
21 explicit affected versions
8 explicit affected versions
7 explicit affected versions
13 explicit affected versions
7 explicit affected versions
10 explicit affected versions
14 explicit affected versions
25 explicit affected versions
12 explicit affected versions
18 explicit affected versions
24 explicit affected versions
3 explicit affected versions
16 explicit affected versions
19 explicit affected versions
43 explicit affected versions
11 explicit affected versions
35 explicit affected versions
12 explicit affected versions
13 explicit affected versions
6 explicit affected versions
12 explicit affected versions
1 explicit affected versions
50 explicit affected versions
11 explicit affected versions
12 explicit affected versions
15 explicit affected versions
27 explicit affected versions
12 explicit affected versions
7 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
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]/
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075
- https://git.kernel.org/stable/c/5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075
- https://git.kernel.org/stable/c/8f149bcc4d91ac92b32ff4949b291e6ed883dc42
- https://git.kernel.org/stable/c/a71ddd5b87cda687efa28e049e85e923689bcef9
- https://ubuntu.com/security/CVE-2024-56613
- https://ubuntu.com/security/notices/USN-7379-1
- https://ubuntu.com/security/notices/USN-7379-2
- https://ubuntu.com/security/notices/USN-7380-1
- https://ubuntu.com/security/notices/USN-7381-1
- https://ubuntu.com/security/notices/USN-7382-1
- https://ubuntu.com/security/notices/USN-7449-1
- https://ubuntu.com/security/notices/USN-7449-2
- https://ubuntu.com/security/notices/USN-7450-1
- https://ubuntu.com/security/notices/USN-7451-1
- https://ubuntu.com/security/notices/USN-7452-1
- https://ubuntu.com/security/notices/USN-7453-1
- https://ubuntu.com/security/notices/USN-7468-1
- https://ubuntu.com/security/notices/USN-7523-1
- https://ubuntu.com/security/notices/USN-7524-1
- https://www.cve.org/CVERecord?id=CVE-2024-56613