{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-56613", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-12-27T14:03:06.014Z", "datePublished": "2024-12-27T14:51:18.068Z", "dateUpdated": "2024-12-27T14:51:18.068Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-12-27T14:51:18.068Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/numa: fix memory leak due to the overwritten vma->numab_state\n\n[Problem Description]\nWhen running the hackbench program of LTP, the following memory leak is\nreported by kmemleak.\n\n # /opt/ltp/testcases/bin/hackbench 20 thread 1000\n Running with 20*40 (== 800) tasks.\n\n # dmesg | grep kmemleak\n ...\n kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n\n # cat /sys/kernel/debug/kmemleak\n unreferenced object 0xffff888cd8ca2c40 (size 64):\n comm \"hackbench\", pid 17142, jiffies 4299780315\n hex dump (first 32 bytes):\n ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I.....\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc bff18fd4):\n [<ffffffff81419a89>] __kmalloc_cache_noprof+0x2f9/0x3f0\n [<ffffffff8113f715>] task_numa_work+0x725/0xa00\n [<ffffffff8110f878>] task_work_run+0x58/0x90\n [<ffffffff81ddd9f8>] syscall_exit_to_user_mode+0x1c8/0x1e0\n [<ffffffff81dd78d5>] do_syscall_64+0x85/0x150\n [<ffffffff81e0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ...\n\nThis issue can be consistently reproduced on three different servers:\n * a 448-core server\n * a 256-core server\n * a 192-core server\n\n[Root Cause]\nSince multiple threads are created by the hackbench program (along with\nthe command argument 'thread'), a shared vma might be accessed by two or\nmore cores simultaneously. When two or more cores observe that\nvma->numab_state is NULL at the same time, vma->numab_state will be\noverwritten.\n\nAlthough current code ensures that only one thread scans the VMAs in a\nsingle 'numa_scan_period', there might be a chance for another thread\nto enter in the next 'numa_scan_period' while we have not gotten till\nnumab_state allocation [1].\n\nNote that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000`\ncannot the reproduce the issue. It is verified with 200+ test runs.\n\n[Solution]\nUse the cmpxchg atomic operation to ensure that only one thread executes\nthe vma->numab_state assignment.\n\n[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["kernel/sched/fair.c"], "versions": [{"version": "ef6a22b70f6d90449a5c797b8968a682824e2011", "lessThan": "8f149bcc4d91ac92b32ff4949b291e6ed883dc42", "status": "affected", "versionType": "git"}, {"version": "ef6a22b70f6d90449a5c797b8968a682824e2011", "lessThan": "a71ddd5b87cda687efa28e049e85e923689bcef9", "status": "affected", "versionType": "git"}, {"version": "ef6a22b70f6d90449a5c797b8968a682824e2011", "lessThan": "5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["kernel/sched/fair.c"], "versions": [{"version": "6.4", "status": "affected"}, {"version": "0", "lessThan": "6.4", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.66", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12.5", "lessThanOrEqual": "6.12.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.13-rc2", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/8f149bcc4d91ac92b32ff4949b291e6ed883dc42"}, {"url": "https://git.kernel.org/stable/c/a71ddd5b87cda687efa28e049e85e923689bcef9"}, {"url": "https://git.kernel.org/stable/c/5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075"}], "title": "sched/numa: fix memory leak due to the overwritten vma->numab_state", "x_generator": {"engine": "bippy-5f407fcff5a0"}}}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "26B700EE-A79C-4047-8214-099FACC0BEB5", "versionEndExcluding": "6.6.66", "versionStartIncluding": "6.4", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "9501D045-7A94-42CA-8B03-821BE94A65B7", "versionEndExcluding": "6.12.5", "versionStartIncluding": "6.7", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:*", "matchCriteriaId": "62567B3C-6CEE-46D0-BC2E-B3717FBF7D13", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/numa: fix memory leak due to the overwritten vma->numab_state\n\n[Problem Description]\nWhen running the hackbench program of LTP, the following memory leak is\nreported by kmemleak.\n\n # /opt/ltp/testcases/bin/hackbench 20 thread 1000\n Running with 20*40 (== 800) tasks.\n\n # dmesg | grep kmemleak\n ...\n kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n\n # cat /sys/kernel/debug/kmemleak\n unreferenced object 0xffff888cd8ca2c40 (size 64):\n comm \"hackbench\", pid 17142, jiffies 4299780315\n hex dump (first 32 bytes):\n ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I.....\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc bff18fd4):\n [<ffffffff81419a89>] __kmalloc_cache_noprof+0x2f9/0x3f0\n [<ffffffff8113f715>] task_numa_work+0x725/0xa00\n [<ffffffff8110f878>] task_work_run+0x58/0x90\n [<ffffffff81ddd9f8>] syscall_exit_to_user_mode+0x1c8/0x1e0\n [<ffffffff81dd78d5>] do_syscall_64+0x85/0x150\n [<ffffffff81e0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ...\n\nThis issue can be consistently reproduced on three different servers:\n * a 448-core server\n * a 256-core server\n * a 192-core server\n\n[Root Cause]\nSince multiple threads are created by the hackbench program (along with\nthe command argument 'thread'), a shared vma might be accessed by two or\nmore cores simultaneously. When two or more cores observe that\nvma->numab_state is NULL at the same time, vma->numab_state will be\noverwritten.\n\nAlthough current code ensures that only one thread scans the VMAs in a\nsingle 'numa_scan_period', there might be a chance for another thread\nto enter in the next 'numa_scan_period' while we have not gotten till\nnumab_state allocation [1].\n\nNote that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000`\ncannot the reproduce the issue. It is verified with 200+ test runs.\n\n[Solution]\nUse the cmpxchg atomic operation to ensure that only one thread executes\nthe vma->numab_state assignment.\n\n[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/numa: se corrige la p\u00e9rdida de memoria debido a la sobrescritura de vma-&gt;numab_state [Descripci\u00f3n del problema] Al ejecutar el programa hackbench de LTP, kmemleak informa la siguiente p\u00e9rdida de memoria. # /opt/ltp/testcases/bin/hackbench 20 thread 1000 Se ejecuta con 20*40 (== 800) tareas. # dmesg | grep kmemleak ... kmemleak: 480 nuevas fugas de memoria sospechosas (consulte /sys/kernel/debug/kmemleak) kmemleak: 665 nuevas fugas de memoria sospechosas (consulte /sys/kernel/debug/kmemleak) # cat /sys/kernel/debug/kmemleak objeto sin referencia 0xffff888cd8ca2c40 (tama\u00f1o 64): comm \"hackbench\", pid 17142, jiffies 4299780315 volcado hexadecimal (primeros 32 bytes): ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....LI.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso (crc bff18fd4): [] __kmalloc_cache_noprof+0x2f9/0x3f0 [] tarea_numa_work+0x725/0xa00 [] tarea_work_run+0x58/0x90 [] llamada_al_sistema_salir_al_modo_usuario+0x1c8/0x1e0 [] hacer_llamada_al_sistema_64+0x85/0x150 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e ... Este problema se puede reproducir consistentemente en tres servidores diferentes: * un servidor de 448 n\u00facleos * un servidor de 256 n\u00facleos * un servidor de 192 n\u00facleos [Causa ra\u00edz] Dado que el programa hackbench crea m\u00faltiples subprocesos (junto con el argumento de comando 'thread'), dos o m\u00e1s n\u00facleos pueden acceder simult\u00e1neamente a un VMA compartido. Cuando dos o m\u00e1s n\u00facleos observan que vma-&gt;numab_state es NULL al mismo tiempo, se sobrescribir\u00e1 vma-&gt;numab_state. Aunque el c\u00f3digo actual garantiza que solo un subproceso escanee los VMA en un solo 'numa_scan_period', puede haber una posibilidad de que otro subproceso ingrese en el siguiente 'numa_scan_period' mientras no hayamos obtenido hasta la asignaci\u00f3n de numab_state [1]. Tenga en cuenta que el comando `/opt/ltp/testcases/bin/hackbench 50 process 1000` no puede reproducir el problema. Esto se ha verificado con m\u00e1s de 200 ejecuciones de pruebas. [Soluci\u00f3n] Utilice la operaci\u00f3n at\u00f3mica cmpxchg para asegurarse de que solo un subproceso ejecute la asignaci\u00f3n vma-&gt;numab_state. [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/"}], "id": "CVE-2024-56613", "lastModified": "2025-01-08T16:51:18.680", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2024-12-27T15:15:20.793", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/8f149bcc4d91ac92b32ff4949b291e6ed883dc42"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/a71ddd5b87cda687efa28e049e85e923689bcef9"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-401"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: sched/numa: fix memory leak due to the overwritten vma->numab_state", "id": "2334491", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2334491"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\nsched/numa: fix memory leak due to the overwritten vma->numab_state\n[Problem Description]\nWhen running the hackbench program of LTP, the following memory leak is\nreported by kmemleak.\n# /opt/ltp/testcases/bin/hackbench 20 thread 1000\nRunning with 20*40 (== 800) tasks.\n# dmesg | grep kmemleak\n...\nkmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n# cat /sys/kernel/debug/kmemleak\nunreferenced object 0xffff888cd8ca2c40 (size 64):\ncomm \"hackbench\", pid 17142, jiffies 4299780315\nhex dump (first 32 bytes):\nac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I.....\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\nbacktrace (crc bff18fd4):\n[<ffffffff81419a89>] __kmalloc_cache_noprof+0x2f9/0x3f0\n[<ffffffff8113f715>] task_numa_work+0x725/0xa00\n[<ffffffff8110f878>] task_work_run+0x58/0x90\n[<ffffffff81ddd9f8>] syscall_exit_to_user_mode+0x1c8/0x1e0\n[<ffffffff81dd78d5>] do_syscall_64+0x85/0x150\n[<ffffffff81e0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n...\nThis issue can be consistently reproduced on three different servers:\n* a 448-core server\n* a 256-core server\n* a 192-core server\n[Root Cause]\nSince multiple threads are created by the hackbench program (along with\nthe command argument 'thread'), a shared vma might be accessed by two or\nmore cores simultaneously. When two or more cores observe that\nvma->numab_state is NULL at the same time, vma->numab_state will be\noverwritten.\nAlthough current code ensures that only one thread scans the VMAs in a\nsingle 'numa_scan_period', there might be a chance for another thread\nto enter in the next 'numa_scan_period' while we have not gotten till\nnumab_state allocation [1].\nNote that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000`\ncannot the reproduce the issue. It is verified with 200+ test runs.\n[Solution]\nUse the cmpxchg atomic operation to ensure that only one thread executes\nthe vma->numab_state assignment.\n[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/"], "name": "CVE-2024-56613", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-12-27T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-56613\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-56613\nhttps://lore.kernel.org/linux-cve-announce/2024122707-CVE-2024-56613-0897@gregkh/T"], "threat_severity": "Moderate"}