Executive Summary

Informations
Name CVE-2024-56613 First vendor Publication 2024-12-27
Vendor Cve Last vendor Modification 2025-01-08

Security-Database Scoring CVSS v3

Cvss vector : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Overall CVSS Score 5.5
Base Score 5.5 Environmental Score 5.5
impact SubScore 3.6 Temporal Score 5.5
Exploitabality Sub Score 1.8
 
Attack Vector Local Attack Complexity Low
Privileges Required Low User Interaction None
Scope Unchanged Confidentiality Impact None
Integrity Impact None Availability Impact High
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score N/A Attack Range N/A
Cvss Impact Score N/A Attack Complexity N/A
Cvss Expoit Score N/A Authentication N/A
Calculate full CVSS 2.0 Vectors scores

Detail

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

Original Source

Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56613

CWE : Common Weakness Enumeration

% Id Name
100 % CWE-401 Failure to Release Memory Before Removing Last Reference ('Memory Leak')

CPE : Common Platform Enumeration

TypeDescriptionCount
Application 8
Os 3668

Sources (Detail)

https://git.kernel.org/stable/c/5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075
https://git.kernel.org/stable/c/8f149bcc4d91ac92b32ff4949b291e6ed883dc42
https://git.kernel.org/stable/c/a71ddd5b87cda687efa28e049e85e923689bcef9
Source Url

Alert History

If you want to see full details history, please login or register.
0
1
Date Informations
2025-01-08 21:20:46
  • Multiple Updates
2024-12-27 21:20:28
  • First insertion