GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2024-56613 (GCVE-0-2024-56613)

Vulnerability from cvelistv5 – Published: 2024-12-27 14:51 – Updated: 2026-05-11 20:55
VLAI
Title
sched/numa: fix memory leak due to the overwritten vma->numab_state
Summary
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/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-10-01 20:01 UTC
CWE
  • CWE-401 - Missing Release of Memory after Effective Lifetime
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: ef6a22b70f6d90449a5c797b8968a682824e2011 , < 8f149bcc4d91ac92b32ff4949b291e6ed883dc42 (git)
Affected: ef6a22b70f6d90449a5c797b8968a682824e2011 , < a71ddd5b87cda687efa28e049e85e923689bcef9 (git)
Affected: ef6a22b70f6d90449a5c797b8968a682824e2011 , < 5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075 (git)
guessed Create a notification for this product.
Linux Linux Affected: 6.4
Unaffected: 0 , < 6.4 (semver)
Unaffected: 6.6.66 , ≤ 6.6.* (semver)
Unaffected: 6.12.5 , ≤ 6.12.* (semver)
Unaffected: 6.13 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "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"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2024-56613",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-01T20:01:15.881890Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-401",
                "description": "CWE-401 Missing Release of Memory after Effective Lifetime",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-01T20:07:13.487Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/sched/fair.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8f149bcc4d91ac92b32ff4949b291e6ed883dc42",
              "status": "affected",
              "version": "ef6a22b70f6d90449a5c797b8968a682824e2011",
              "versionType": "git"
            },
            {
              "lessThan": "a71ddd5b87cda687efa28e049e85e923689bcef9",
              "status": "affected",
              "version": "ef6a22b70f6d90449a5c797b8968a682824e2011",
              "versionType": "git"
            },
            {
              "lessThan": "5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075",
              "status": "affected",
              "version": "ef6a22b70f6d90449a5c797b8968a682824e2011",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/sched/fair.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.4"
            },
            {
              "lessThan": "6.4",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.66",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.13",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.66",
                  "versionStartIncluding": "6.4",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.5",
                  "versionStartIncluding": "6.4",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13",
                  "versionStartIncluding": "6.4",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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-\u003enumab_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      [\u003cffffffff81419a89\u003e] __kmalloc_cache_noprof+0x2f9/0x3f0\n      [\u003cffffffff8113f715\u003e] task_numa_work+0x725/0xa00\n      [\u003cffffffff8110f878\u003e] task_work_run+0x58/0x90\n      [\u003cffffffff81ddd9f8\u003e] syscall_exit_to_user_mode+0x1c8/0x1e0\n      [\u003cffffffff81dd78d5\u003e] do_syscall_64+0x85/0x150\n      [\u003cffffffff81e0012b\u003e] 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 \u0027thread\u0027), a shared vma might be accessed by two or\nmore cores simultaneously. When two or more cores observe that\nvma-\u003enumab_state is NULL at the same time, vma-\u003enumab_state will be\noverwritten.\n\nAlthough current code ensures that only one thread scans the VMAs in a\nsingle \u0027numa_scan_period\u0027, there might be a chance for another thread\nto enter in the next \u0027numa_scan_period\u0027 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-\u003enumab_state assignment.\n\n[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:55:51.104Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "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-\u003enumab_state",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-56613",
    "datePublished": "2024-12-27T14:51:18.068Z",
    "dateReserved": "2024-12-27T14:03:06.014Z",
    "dateUpdated": "2026-05-11T20:55:51.104Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-56613",
      "date": "2026-09-15",
      "epss": "0.00203",
      "percentile": "0.10393"
    },
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.4\", \"versionEndExcluding\": \"6.6.66\", \"matchCriteriaId\": \"26B700EE-A79C-4047-8214-099FACC0BEB5\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.7\", \"versionEndExcluding\": \"6.12.5\", \"matchCriteriaId\": \"9501D045-7A94-42CA-8B03-821BE94A65B7\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:*\", \"matchCriteriaId\": \"62567B3C-6CEE-46D0-BC2E-B3717FBF7D13\"}]}]}]",
      "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-\u003enumab_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      [\u003cffffffff81419a89\u003e] __kmalloc_cache_noprof+0x2f9/0x3f0\\n      [\u003cffffffff8113f715\u003e] task_numa_work+0x725/0xa00\\n      [\u003cffffffff8110f878\u003e] task_work_run+0x58/0x90\\n      [\u003cffffffff81ddd9f8\u003e] syscall_exit_to_user_mode+0x1c8/0x1e0\\n      [\u003cffffffff81dd78d5\u003e] do_syscall_64+0x85/0x150\\n      [\u003cffffffff81e0012b\u003e] 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 \u0027thread\u0027), a shared vma might be accessed by two or\\nmore cores simultaneously. When two or more cores observe that\\nvma-\u003enumab_state is NULL at the same time, vma-\u003enumab_state will be\\noverwritten.\\n\\nAlthough current code ensures that only one thread scans the VMAs in a\\nsingle \u0027numa_scan_period\u0027, there might be a chance for another thread\\nto enter in the next \u0027numa_scan_period\u0027 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-\u003enumab_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-\u0026gt;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 \u0027thread\u0027), dos o m\\u00e1s n\\u00facleos pueden acceder simult\\u00e1neamente a un VMA compartido. Cuando dos o m\\u00e1s n\\u00facleos observan que vma-\u0026gt;numab_state es NULL al mismo tiempo, se sobrescribir\\u00e1 vma-\u0026gt;numab_state. Aunque el c\\u00f3digo actual garantiza que solo un subproceso escanee los VMA en un solo \u0027numa_scan_period\u0027, puede haber una posibilidad de que otro subproceso ingrese en el siguiente \u0027numa_scan_period\u0027 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-\u0026gt;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\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"baseScore\": 5.5, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"LOCAL\", \"attackComplexity\": \"LOW\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"NONE\", \"availabilityImpact\": \"HIGH\"}, \"exploitabilityScore\": 1.8, \"impactScore\": 3.6}]}",
      "published": "2024-12-27T15:15:20.793",
      "references": "[{\"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\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Analyzed",
      "weaknesses": "[{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"CWE-401\"}]}]"
    },
    "microsoft_vex": {
      "current_release_date": "2025-03-13T00:00:00.000Z",
      "cve": "CVE-2024-56613",
      "id": "msrc_CVE-2024-56613",
      "initial_release_date": "2024-12-02T00:00:00.000Z",
      "product_status:fixed": "2",
      "product_status:known_affected": "2",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "sched/numa: fix memory leak due to the overwritten vma-\u003enumab_state",
      "url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-56613.json",
      "version": "1"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-56613\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-12-27T15:15:20.793\",\"lastModified\":\"2026-06-17T08:12:33.003\",\"vulnStatus\":\"Modified\",\"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-\u003enumab_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      [\u003cffffffff81419a89\u003e] __kmalloc_cache_noprof+0x2f9/0x3f0\\n      [\u003cffffffff8113f715\u003e] task_numa_work+0x725/0xa00\\n      [\u003cffffffff8110f878\u003e] task_work_run+0x58/0x90\\n      [\u003cffffffff81ddd9f8\u003e] syscall_exit_to_user_mode+0x1c8/0x1e0\\n      [\u003cffffffff81dd78d5\u003e] do_syscall_64+0x85/0x150\\n      [\u003cffffffff81e0012b\u003e] 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 \u0027thread\u0027), a shared vma might be accessed by two or\\nmore cores simultaneously. When two or more cores observe that\\nvma-\u003enumab_state is NULL at the same time, vma-\u003enumab_state will be\\noverwritten.\\n\\nAlthough current code ensures that only one thread scans the VMAs in a\\nsingle \u0027numa_scan_period\u0027, there might be a chance for another thread\\nto enter in the next \u0027numa_scan_period\u0027 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-\u003enumab_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-\u0026gt;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 \u0027thread\u0027), dos o m\u00e1s n\u00facleos pueden acceder simult\u00e1neamente a un VMA compartido. Cuando dos o m\u00e1s n\u00facleos observan que vma-\u0026gt;numab_state es NULL al mismo tiempo, se sobrescribir\u00e1 vma-\u0026gt;numab_state. Aunque el c\u00f3digo actual garantiza que solo un subproceso escanee los VMA en un solo \u0027numa_scan_period\u0027, puede haber una posibilidad de que otro subproceso ingrese en el siguiente \u0027numa_scan_period\u0027 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-\u0026gt;numab_state. [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"kernel/sched/fair.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"ef6a22b70f6d90449a5c797b8968a682824e2011\",\"lessThan\":\"8f149bcc4d91ac92b32ff4949b291e6ed883dc42\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"ef6a22b70f6d90449a5c797b8968a682824e2011\",\"lessThan\":\"a71ddd5b87cda687efa28e049e85e923689bcef9\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"ef6a22b70f6d90449a5c797b8968a682824e2011\",\"lessThan\":\"5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"kernel/sched/fair.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"6.4\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"6.4\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.66\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.5\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.13\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6},{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2025-10-01T20:01:15.881890Z\",\"id\":\"CVE-2024-56613\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-401\"}]},{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-401\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.4\",\"versionEndExcluding\":\"6.6.66\",\"matchCriteriaId\":\"26B700EE-A79C-4047-8214-099FACC0BEB5\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.12.5\",\"matchCriteriaId\":\"9501D045-7A94-42CA-8B03-821BE94A65B7\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"62567B3C-6CEE-46D0-BC2E-B3717FBF7D13\"}]}]}],\"references\":[{\"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\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2025-11-21T13:57:24+00:00",
      "cve": "CVE-2024-56613",
      "id": "CVE-2024-56613",
      "initial_release_date": "2024-12-27T00:00:00+00:00",
      "product_status:known_affected": "136",
      "product_status:known_not_affected": "62",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: sched/numa: fix memory leak due to the overwritten vma-\u003enumab_state",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-56613.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "low",
      "current_release_date": "2026-09-01T13:56:42Z",
      "cve": "CVE-2024-56613",
      "id": "CVE-2024-56613",
      "initial_release_date": "2025-04-01T01:44:19Z",
      "product_status:known_affected": "394",
      "product_status:known_not_affected": "494",
      "product_status:recommended": "396",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2024-56613",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-56613.json",
      "version": "39"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 5.5, \"attackVector\": \"LOCAL\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"NONE\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-56613\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-10-01T20:01:15.881890Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-401\", \"description\": \"CWE-401 Missing Release of Memory after Effective Lifetime\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-10-01T15:43:07.847Z\"}}], \"cna\": {\"title\": \"sched/numa: fix memory leak due to the overwritten vma-\u003enumab_state\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"ef6a22b70f6d90449a5c797b8968a682824e2011\", \"lessThan\": \"8f149bcc4d91ac92b32ff4949b291e6ed883dc42\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"ef6a22b70f6d90449a5c797b8968a682824e2011\", \"lessThan\": \"a71ddd5b87cda687efa28e049e85e923689bcef9\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"ef6a22b70f6d90449a5c797b8968a682824e2011\", \"lessThan\": \"5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075\", \"versionType\": \"git\"}], \"programFiles\": [\"kernel/sched/fair.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"6.4\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"6.4\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.6.66\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.12.5\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.12.*\"}, {\"status\": \"unaffected\", \"version\": \"6.13\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"kernel/sched/fair.c\"], \"defaultStatus\": \"affected\"}], \"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\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"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-\u003enumab_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      [\u003cffffffff81419a89\u003e] __kmalloc_cache_noprof+0x2f9/0x3f0\\n      [\u003cffffffff8113f715\u003e] task_numa_work+0x725/0xa00\\n      [\u003cffffffff8110f878\u003e] task_work_run+0x58/0x90\\n      [\u003cffffffff81ddd9f8\u003e] syscall_exit_to_user_mode+0x1c8/0x1e0\\n      [\u003cffffffff81dd78d5\u003e] do_syscall_64+0x85/0x150\\n      [\u003cffffffff81e0012b\u003e] 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 \u0027thread\u0027), a shared vma might be accessed by two or\\nmore cores simultaneously. When two or more cores observe that\\nvma-\u003enumab_state is NULL at the same time, vma-\u003enumab_state will be\\noverwritten.\\n\\nAlthough current code ensures that only one thread scans the VMAs in a\\nsingle \u0027numa_scan_period\u0027, there might be a chance for another thread\\nto enter in the next \u0027numa_scan_period\u0027 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-\u003enumab_state assignment.\\n\\n[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.6.66\", \"versionStartIncluding\": \"6.4\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.12.5\", \"versionStartIncluding\": \"6.4\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.13\", \"versionStartIncluding\": \"6.4\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-05-11T20:55:51.104Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-56613\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-05-11T20:55:51.104Z\", \"dateReserved\": \"2024-12-27T14:03:06.014Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-12-27T14:51:18.068Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…