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

CVE-2024-56592 (GCVE-0-2024-56592)

Vulnerability from cvelistv5 – Published: 2024-12-27 14:50 – Updated: 2026-05-11 20:55
VLAI
Title
bpf: Call free_htab_elem() after htab_unlock_bucket()
Summary
In the Linux kernel, the following vulnerability has been resolved: bpf: Call free_htab_elem() after htab_unlock_bucket() For htab of maps, when the map is removed from the htab, it may hold the last reference of the map. bpf_map_fd_put_ptr() will invoke bpf_map_free_id() to free the id of the removed map element. However, bpf_map_fd_put_ptr() is invoked while holding a bucket lock (raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock (spinlock_t), triggering the following lockdep warning: ============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted ----------------------------- test_maps/4881 is trying to lock: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: <TASK> dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e One way to fix the lockdep warning is using raw_spinlock_t for map_idr_lock as well. However, bpf_map_alloc_id() invokes idr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a similar lockdep warning because the slab's lock (s->cpu_slab->lock) is still a spinlock. Instead of changing map_idr_lock's type, fix the issue by invoking htab_put_fd_value() after htab_unlock_bucket(). However, only deferring the invocation of htab_put_fd_value() is not enough, because the old map pointers in htab of maps can not be saved during batched deletion. Therefore, also defer the invocation of free_htab_elem(), so these to-be-freed elements could be linked together similar to lru map. There are four callers for ->map_fd_put_ptr: (1) alloc_htab_elem() (through htab_put_fd_value()) It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation of htab_put_fd_value() can not simply move after htab_unlock_bucket(), because the old element has already been stashed in htab->extra_elems. It may be reused immediately after htab_unlock_bucket() and the invocation of htab_put_fd_value() after htab_unlock_bucket() may release the newly-added element incorrectly. Therefore, saving the map pointer of the old element for htab of maps before unlocking the bucket and releasing the map_ptr after unlock. Beside the map pointer in the old element, should do the same thing for the special fields in the old element as well. (2) free_htab_elem() (through htab_put_fd_value()) Its caller includes __htab_map_lookup_and_delete_elem(), htab_map_delete_elem() and __htab_map_lookup_and_delete_batch(). For htab_map_delete_elem(), simply invoke free_htab_elem() after htab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just like lru map, linking the to-be-freed element into node_to_free list and invoking free_htab_elem() for these element after unlock. It is safe to reuse batch_flink as the link for node_to_free, because these elements have been removed from the hash llist. Because htab of maps doesn't support lookup_and_delete operation, __htab_map_lookup_and_delete_elem() doesn't have the problem, so kept it as ---truncated---
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: f3f1c054c288bb6e503005e6d73611151ed20e91 , < 10e8a2dec9ff1b81de8e892b0850924038adbc6d (git)
Affected: f3f1c054c288bb6e503005e6d73611151ed20e91 , < a50b4aa3007e63a590d501341f304676ebc74b3b (git)
Affected: f3f1c054c288bb6e503005e6d73611151ed20e91 , < b9e9ed90b10c82a4e9d4d70a2890f06bfcdd3b78 (git)
guessed Create a notification for this product.
Linux Linux Affected: 4.13
Unaffected: 0 , < 4.13 (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": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/hashtab.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "10e8a2dec9ff1b81de8e892b0850924038adbc6d",
              "status": "affected",
              "version": "f3f1c054c288bb6e503005e6d73611151ed20e91",
              "versionType": "git"
            },
            {
              "lessThan": "a50b4aa3007e63a590d501341f304676ebc74b3b",
              "status": "affected",
              "version": "f3f1c054c288bb6e503005e6d73611151ed20e91",
              "versionType": "git"
            },
            {
              "lessThan": "b9e9ed90b10c82a4e9d4d70a2890f06bfcdd3b78",
              "status": "affected",
              "version": "f3f1c054c288bb6e503005e6d73611151ed20e91",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/hashtab.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.13"
            },
            {
              "lessThan": "4.13",
              "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": "4.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.5",
                  "versionStartIncluding": "4.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13",
                  "versionStartIncluding": "4.13",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Call free_htab_elem() after htab_unlock_bucket()\n\nFor htab of maps, when the map is removed from the htab, it may hold the\nlast reference of the map. bpf_map_fd_put_ptr() will invoke\nbpf_map_free_id() to free the id of the removed map element. However,\nbpf_map_fd_put_ptr() is invoked while holding a bucket lock\n(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock\n(spinlock_t), triggering the following lockdep warning:\n\n  =============================\n  [ BUG: Invalid wait context ]\n  6.11.0-rc4+ #49 Not tainted\n  -----------------------------\n  test_maps/4881 is trying to lock:\n  ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70\n  other info that might help us debug this:\n  context-{5:5}\n  2 locks held by test_maps/4881:\n   #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270\n   #1: ffff888149ced148 (\u0026htab-\u003elockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80\n  stack backtrace:\n  CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...\n  Call Trace:\n   \u003cTASK\u003e\n   dump_stack_lvl+0x6e/0xb0\n   dump_stack+0x10/0x20\n   __lock_acquire+0x73e/0x36c0\n   lock_acquire+0x182/0x450\n   _raw_spin_lock_irqsave+0x43/0x70\n   bpf_map_free_id.part.0+0x21/0x70\n   bpf_map_put+0xcf/0x110\n   bpf_map_fd_put_ptr+0x9a/0xb0\n   free_htab_elem+0x69/0xe0\n   htab_map_update_elem+0x50f/0xa80\n   bpf_fd_htab_map_update_elem+0x131/0x270\n   htab_map_update_elem+0x50f/0xa80\n   bpf_fd_htab_map_update_elem+0x131/0x270\n   bpf_map_update_value+0x266/0x380\n   __sys_bpf+0x21bb/0x36b0\n   __x64_sys_bpf+0x45/0x60\n   x64_sys_call+0x1b2a/0x20d0\n   do_syscall_64+0x5d/0x100\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nOne way to fix the lockdep warning is using raw_spinlock_t for\nmap_idr_lock as well. However, bpf_map_alloc_id() invokes\nidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a\nsimilar lockdep warning because the slab\u0027s lock (s-\u003ecpu_slab-\u003elock) is\nstill a spinlock.\n\nInstead of changing map_idr_lock\u0027s type, fix the issue by invoking\nhtab_put_fd_value() after htab_unlock_bucket(). However, only deferring\nthe invocation of htab_put_fd_value() is not enough, because the old map\npointers in htab of maps can not be saved during batched deletion.\nTherefore, also defer the invocation of free_htab_elem(), so these\nto-be-freed elements could be linked together similar to lru map.\n\nThere are four callers for -\u003emap_fd_put_ptr:\n\n(1) alloc_htab_elem() (through htab_put_fd_value())\nIt invokes -\u003emap_fd_put_ptr() under a raw_spinlock_t. The invocation of\nhtab_put_fd_value() can not simply move after htab_unlock_bucket(),\nbecause the old element has already been stashed in htab-\u003eextra_elems.\nIt may be reused immediately after htab_unlock_bucket() and the\ninvocation of htab_put_fd_value() after htab_unlock_bucket() may release\nthe newly-added element incorrectly. Therefore, saving the map pointer\nof the old element for htab of maps before unlocking the bucket and\nreleasing the map_ptr after unlock. Beside the map pointer in the old\nelement, should do the same thing for the special fields in the old\nelement as well.\n\n(2) free_htab_elem() (through htab_put_fd_value())\nIts caller includes __htab_map_lookup_and_delete_elem(),\nhtab_map_delete_elem() and __htab_map_lookup_and_delete_batch().\n\nFor htab_map_delete_elem(), simply invoke free_htab_elem() after\nhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just\nlike lru map, linking the to-be-freed element into node_to_free list\nand invoking free_htab_elem() for these element after unlock. It is safe\nto reuse batch_flink as the link for node_to_free, because these\nelements have been removed from the hash llist.\n\nBecause htab of maps doesn\u0027t support lookup_and_delete operation,\n__htab_map_lookup_and_delete_elem() doesn\u0027t have the problem, so kept\nit as\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:55:26.485Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/10e8a2dec9ff1b81de8e892b0850924038adbc6d"
        },
        {
          "url": "https://git.kernel.org/stable/c/a50b4aa3007e63a590d501341f304676ebc74b3b"
        },
        {
          "url": "https://git.kernel.org/stable/c/b9e9ed90b10c82a4e9d4d70a2890f06bfcdd3b78"
        }
      ],
      "title": "bpf: Call free_htab_elem() after htab_unlock_bucket()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-56592",
    "datePublished": "2024-12-27T14:50:59.673Z",
    "dateReserved": "2024-12-27T14:03:06.003Z",
    "dateUpdated": "2026-05-11T20:55:26.485Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-56592",
      "date": "2026-09-16",
      "epss": "0.00218",
      "percentile": "0.12351"
    },
    "fkie_nvd": {
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Call free_htab_elem() after htab_unlock_bucket()\\n\\nFor htab of maps, when the map is removed from the htab, it may hold the\\nlast reference of the map. bpf_map_fd_put_ptr() will invoke\\nbpf_map_free_id() to free the id of the removed map element. However,\\nbpf_map_fd_put_ptr() is invoked while holding a bucket lock\\n(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock\\n(spinlock_t), triggering the following lockdep warning:\\n\\n  =============================\\n  [ BUG: Invalid wait context ]\\n  6.11.0-rc4+ #49 Not tainted\\n  -----------------------------\\n  test_maps/4881 is trying to lock:\\n  ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70\\n  other info that might help us debug this:\\n  context-{5:5}\\n  2 locks held by test_maps/4881:\\n   #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270\\n   #1: ffff888149ced148 (\u0026htab-\u003elockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80\\n  stack backtrace:\\n  CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49\\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...\\n  Call Trace:\\n   \u003cTASK\u003e\\n   dump_stack_lvl+0x6e/0xb0\\n   dump_stack+0x10/0x20\\n   __lock_acquire+0x73e/0x36c0\\n   lock_acquire+0x182/0x450\\n   _raw_spin_lock_irqsave+0x43/0x70\\n   bpf_map_free_id.part.0+0x21/0x70\\n   bpf_map_put+0xcf/0x110\\n   bpf_map_fd_put_ptr+0x9a/0xb0\\n   free_htab_elem+0x69/0xe0\\n   htab_map_update_elem+0x50f/0xa80\\n   bpf_fd_htab_map_update_elem+0x131/0x270\\n   htab_map_update_elem+0x50f/0xa80\\n   bpf_fd_htab_map_update_elem+0x131/0x270\\n   bpf_map_update_value+0x266/0x380\\n   __sys_bpf+0x21bb/0x36b0\\n   __x64_sys_bpf+0x45/0x60\\n   x64_sys_call+0x1b2a/0x20d0\\n   do_syscall_64+0x5d/0x100\\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\\n\\nOne way to fix the lockdep warning is using raw_spinlock_t for\\nmap_idr_lock as well. However, bpf_map_alloc_id() invokes\\nidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a\\nsimilar lockdep warning because the slab\u0027s lock (s-\u003ecpu_slab-\u003elock) is\\nstill a spinlock.\\n\\nInstead of changing map_idr_lock\u0027s type, fix the issue by invoking\\nhtab_put_fd_value() after htab_unlock_bucket(). However, only deferring\\nthe invocation of htab_put_fd_value() is not enough, because the old map\\npointers in htab of maps can not be saved during batched deletion.\\nTherefore, also defer the invocation of free_htab_elem(), so these\\nto-be-freed elements could be linked together similar to lru map.\\n\\nThere are four callers for -\u003emap_fd_put_ptr:\\n\\n(1) alloc_htab_elem() (through htab_put_fd_value())\\nIt invokes -\u003emap_fd_put_ptr() under a raw_spinlock_t. The invocation of\\nhtab_put_fd_value() can not simply move after htab_unlock_bucket(),\\nbecause the old element has already been stashed in htab-\u003eextra_elems.\\nIt may be reused immediately after htab_unlock_bucket() and the\\ninvocation of htab_put_fd_value() after htab_unlock_bucket() may release\\nthe newly-added element incorrectly. Therefore, saving the map pointer\\nof the old element for htab of maps before unlocking the bucket and\\nreleasing the map_ptr after unlock. Beside the map pointer in the old\\nelement, should do the same thing for the special fields in the old\\nelement as well.\\n\\n(2) free_htab_elem() (through htab_put_fd_value())\\nIts caller includes __htab_map_lookup_and_delete_elem(),\\nhtab_map_delete_elem() and __htab_map_lookup_and_delete_batch().\\n\\nFor htab_map_delete_elem(), simply invoke free_htab_elem() after\\nhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just\\nlike lru map, linking the to-be-freed element into node_to_free list\\nand invoking free_htab_elem() for these element after unlock. It is safe\\nto reuse batch_flink as the link for node_to_free, because these\\nelements have been removed from the hash llist.\\n\\nBecause htab of maps doesn\u0027t support lookup_and_delete operation,\\n__htab_map_lookup_and_delete_elem() doesn\u0027t have the problem, so kept\\nit as\\n---truncated---\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Llamar a free_htab_elem() despu\\u00e9s de htab_unlock_bucket() Para htab de mapas, cuando el mapa se elimina del htab, puede contener la \\u00faltima referencia del mapa. bpf_map_fd_put_ptr() invocar\\u00e1 bpf_map_free_id() para liberar el id del elemento del mapa eliminado. Sin embargo, bpf_map_fd_put_ptr() se invoca mientras se mantiene un bloqueo de dep\\u00f3sito (raw_spin_lock_t), y bpf_map_free_id() intenta adquirir map_idr_lock (spinlock_t), lo que activa la siguiente advertencia de lockdep: ============================== [ ERROR: Contexto de espera no v\\u00e1lido ] 6.11.0-rc4+ #49 No contaminado ----------------------------- test_maps/4881 est\\u00e1 intentando bloquear: ffffffff84884578 (map_idr_lock){+...}-{3:3}, en: bpf_map_free_id.part.0+0x21/0x70 otra informaci\\u00f3n que podr\\u00eda ayudarnos a depurar esto: context-{5:5} 2 bloqueos mantenidos por test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, en: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (\u0026amp;htab-\u0026gt;lockdep_key#2){....}-{2:2}, en: htab_map_update_elem+0x178/0xa80 seguimiento de pila: CPU: 0 UID: 0 PID: 4881 Comm: test_maps No contaminado 6.11.0-rc4+ #49 Nombre del hardware: PC est\\u00e1ndar QEMU (i440FX + PIIX, 1996), ... Seguimiento de llamadas:  dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Una forma de corregir la advertencia de lockdep es usar raw_spinlock_t tambi\\u00e9n para map_idr_lock. Sin embargo, bpf_map_alloc_id() invoca idr_alloc_cyclic() despu\\u00e9s de adquirir map_idr_lock, activar\\u00e1 una advertencia de lockdep similar porque el bloqueo del slab (s-\u0026gt;cpu_slab-\u0026gt;lock) sigue siendo un spinlock. En lugar de cambiar el tipo de map_idr_lock, solucione el problema invocando htab_put_fd_value() despu\\u00e9s de htab_unlock_bucket(). Sin embargo, solo aplazar la invocaci\\u00f3n de htab_put_fd_value() no es suficiente, porque los punteros de mapa antiguos en htab de mapas no se pueden guardar durante la eliminaci\\u00f3n por lotes. Por lo tanto, tambi\\u00e9n aplace la invocaci\\u00f3n de free_htab_elem(), para que estos elementos a liberar se puedan vincular entre s\\u00ed de forma similar a lru map. Hay cuatro invocadores para -\u0026gt;map_fd_put_ptr: (1) alloc_htab_elem() (a trav\\u00e9s de htab_put_fd_value()) Invoca -\u0026gt;map_fd_put_ptr() bajo un raw_spinlock_t. La invocaci\\u00f3n de htab_put_fd_value() no se puede mover simplemente despu\\u00e9s de htab_unlock_bucket(), porque el elemento antiguo ya se ha almacenado en htab-\u0026gt;extra_elems. Se puede reutilizar inmediatamente despu\\u00e9s de htab_unlock_bucket() y la invocaci\\u00f3n de htab_put_fd_value() despu\\u00e9s de htab_unlock_bucket() puede liberar el elemento reci\\u00e9n agregado de manera incorrecta. Por lo tanto, se guarda el puntero del mapa del elemento antiguo para htab de mapas antes de desbloquear el dep\\u00f3sito y se libera map_ptr despu\\u00e9s del desbloqueo. Adem\\u00e1s del puntero del mapa en el elemento antiguo, se debe hacer lo mismo para los campos especiales en el elemento antiguo tambi\\u00e9n. (2) free_htab_elem() (a trav\\u00e9s de htab_put_fd_value()) Su llamador incluye __htab_map_lookup_and_delete_elem(), htab_map_delete_elem() y __htab_map_lookup_and_delete_batch(). Para htab_map_delete_elem(), simplemente invoque free_htab_elem() despu\\u00e9s de htab_unlock_bucket(). Para __htab_map_lookup_and_delete_batch(), al igual que lru map, vinculando el elemento a liberar en la lista node_to_free e invocando free_htab_elem() para estos elementos despu\\u00e9s del desbloqueo. Es seguro reutilizar batch_flink como el enlace para node_to_free, ---truncado---\"}]",
      "id": "CVE-2024-56592",
      "lastModified": "2024-12-27T15:15:18.500",
      "published": "2024-12-27T15:15:18.500",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/10e8a2dec9ff1b81de8e892b0850924038adbc6d\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/a50b4aa3007e63a590d501341f304676ebc74b3b\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/b9e9ed90b10c82a4e9d4d70a2890f06bfcdd3b78\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Awaiting Analysis"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-56592\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-12-27T15:15:18.500\",\"lastModified\":\"2026-06-17T08:12:29.633\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Call free_htab_elem() after htab_unlock_bucket()\\n\\nFor htab of maps, when the map is removed from the htab, it may hold the\\nlast reference of the map. bpf_map_fd_put_ptr() will invoke\\nbpf_map_free_id() to free the id of the removed map element. However,\\nbpf_map_fd_put_ptr() is invoked while holding a bucket lock\\n(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock\\n(spinlock_t), triggering the following lockdep warning:\\n\\n  =============================\\n  [ BUG: Invalid wait context ]\\n  6.11.0-rc4+ #49 Not tainted\\n  -----------------------------\\n  test_maps/4881 is trying to lock:\\n  ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70\\n  other info that might help us debug this:\\n  context-{5:5}\\n  2 locks held by test_maps/4881:\\n   #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270\\n   #1: ffff888149ced148 (\u0026htab-\u003elockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80\\n  stack backtrace:\\n  CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49\\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...\\n  Call Trace:\\n   \u003cTASK\u003e\\n   dump_stack_lvl+0x6e/0xb0\\n   dump_stack+0x10/0x20\\n   __lock_acquire+0x73e/0x36c0\\n   lock_acquire+0x182/0x450\\n   _raw_spin_lock_irqsave+0x43/0x70\\n   bpf_map_free_id.part.0+0x21/0x70\\n   bpf_map_put+0xcf/0x110\\n   bpf_map_fd_put_ptr+0x9a/0xb0\\n   free_htab_elem+0x69/0xe0\\n   htab_map_update_elem+0x50f/0xa80\\n   bpf_fd_htab_map_update_elem+0x131/0x270\\n   htab_map_update_elem+0x50f/0xa80\\n   bpf_fd_htab_map_update_elem+0x131/0x270\\n   bpf_map_update_value+0x266/0x380\\n   __sys_bpf+0x21bb/0x36b0\\n   __x64_sys_bpf+0x45/0x60\\n   x64_sys_call+0x1b2a/0x20d0\\n   do_syscall_64+0x5d/0x100\\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\\n\\nOne way to fix the lockdep warning is using raw_spinlock_t for\\nmap_idr_lock as well. However, bpf_map_alloc_id() invokes\\nidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a\\nsimilar lockdep warning because the slab\u0027s lock (s-\u003ecpu_slab-\u003elock) is\\nstill a spinlock.\\n\\nInstead of changing map_idr_lock\u0027s type, fix the issue by invoking\\nhtab_put_fd_value() after htab_unlock_bucket(). However, only deferring\\nthe invocation of htab_put_fd_value() is not enough, because the old map\\npointers in htab of maps can not be saved during batched deletion.\\nTherefore, also defer the invocation of free_htab_elem(), so these\\nto-be-freed elements could be linked together similar to lru map.\\n\\nThere are four callers for -\u003emap_fd_put_ptr:\\n\\n(1) alloc_htab_elem() (through htab_put_fd_value())\\nIt invokes -\u003emap_fd_put_ptr() under a raw_spinlock_t. The invocation of\\nhtab_put_fd_value() can not simply move after htab_unlock_bucket(),\\nbecause the old element has already been stashed in htab-\u003eextra_elems.\\nIt may be reused immediately after htab_unlock_bucket() and the\\ninvocation of htab_put_fd_value() after htab_unlock_bucket() may release\\nthe newly-added element incorrectly. Therefore, saving the map pointer\\nof the old element for htab of maps before unlocking the bucket and\\nreleasing the map_ptr after unlock. Beside the map pointer in the old\\nelement, should do the same thing for the special fields in the old\\nelement as well.\\n\\n(2) free_htab_elem() (through htab_put_fd_value())\\nIts caller includes __htab_map_lookup_and_delete_elem(),\\nhtab_map_delete_elem() and __htab_map_lookup_and_delete_batch().\\n\\nFor htab_map_delete_elem(), simply invoke free_htab_elem() after\\nhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just\\nlike lru map, linking the to-be-freed element into node_to_free list\\nand invoking free_htab_elem() for these element after unlock. It is safe\\nto reuse batch_flink as the link for node_to_free, because these\\nelements have been removed from the hash llist.\\n\\nBecause htab of maps doesn\u0027t support lookup_and_delete operation,\\n__htab_map_lookup_and_delete_elem() doesn\u0027t have the problem, so kept\\nit as\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Llamar a free_htab_elem() despu\u00e9s de htab_unlock_bucket() Para htab de mapas, cuando el mapa se elimina del htab, puede contener la \u00faltima referencia del mapa. bpf_map_fd_put_ptr() invocar\u00e1 bpf_map_free_id() para liberar el id del elemento del mapa eliminado. Sin embargo, bpf_map_fd_put_ptr() se invoca mientras se mantiene un bloqueo de dep\u00f3sito (raw_spin_lock_t), y bpf_map_free_id() intenta adquirir map_idr_lock (spinlock_t), lo que activa la siguiente advertencia de lockdep: ============================== [ ERROR: Contexto de espera no v\u00e1lido ] 6.11.0-rc4+ #49 No contaminado ----------------------------- test_maps/4881 est\u00e1 intentando bloquear: ffffffff84884578 (map_idr_lock){+...}-{3:3}, en: bpf_map_free_id.part.0+0x21/0x70 otra informaci\u00f3n que podr\u00eda ayudarnos a depurar esto: context-{5:5} 2 bloqueos mantenidos por test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, en: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (\u0026amp;htab-\u0026gt;lockdep_key#2){....}-{2:2}, en: htab_map_update_elem+0x178/0xa80 seguimiento de pila: CPU: 0 UID: 0 PID: 4881 Comm: test_maps No contaminado 6.11.0-rc4+ #49 Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), ... Seguimiento de llamadas:  dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Una forma de corregir la advertencia de lockdep es usar raw_spinlock_t tambi\u00e9n para map_idr_lock. Sin embargo, bpf_map_alloc_id() invoca idr_alloc_cyclic() despu\u00e9s de adquirir map_idr_lock, activar\u00e1 una advertencia de lockdep similar porque el bloqueo del slab (s-\u0026gt;cpu_slab-\u0026gt;lock) sigue siendo un spinlock. En lugar de cambiar el tipo de map_idr_lock, solucione el problema invocando htab_put_fd_value() despu\u00e9s de htab_unlock_bucket(). Sin embargo, solo aplazar la invocaci\u00f3n de htab_put_fd_value() no es suficiente, porque los punteros de mapa antiguos en htab de mapas no se pueden guardar durante la eliminaci\u00f3n por lotes. Por lo tanto, tambi\u00e9n aplace la invocaci\u00f3n de free_htab_elem(), para que estos elementos a liberar se puedan vincular entre s\u00ed de forma similar a lru map. Hay cuatro invocadores para -\u0026gt;map_fd_put_ptr: (1) alloc_htab_elem() (a trav\u00e9s de htab_put_fd_value()) Invoca -\u0026gt;map_fd_put_ptr() bajo un raw_spinlock_t. La invocaci\u00f3n de htab_put_fd_value() no se puede mover simplemente despu\u00e9s de htab_unlock_bucket(), porque el elemento antiguo ya se ha almacenado en htab-\u0026gt;extra_elems. Se puede reutilizar inmediatamente despu\u00e9s de htab_unlock_bucket() y la invocaci\u00f3n de htab_put_fd_value() despu\u00e9s de htab_unlock_bucket() puede liberar el elemento reci\u00e9n agregado de manera incorrecta. Por lo tanto, se guarda el puntero del mapa del elemento antiguo para htab de mapas antes de desbloquear el dep\u00f3sito y se libera map_ptr despu\u00e9s del desbloqueo. Adem\u00e1s del puntero del mapa en el elemento antiguo, se debe hacer lo mismo para los campos especiales en el elemento antiguo tambi\u00e9n. (2) free_htab_elem() (a trav\u00e9s de htab_put_fd_value()) Su llamador incluye __htab_map_lookup_and_delete_elem(), htab_map_delete_elem() y __htab_map_lookup_and_delete_batch(). Para htab_map_delete_elem(), simplemente invoque free_htab_elem() despu\u00e9s de htab_unlock_bucket(). Para __htab_map_lookup_and_delete_batch(), al igual que lru map, vinculando el elemento a liberar en la lista node_to_free e invocando free_htab_elem() para estos elementos despu\u00e9s del desbloqueo. Es seguro reutilizar batch_flink como el enlace para node_to_free, ---truncado---\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"kernel/bpf/hashtab.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"f3f1c054c288bb6e503005e6d73611151ed20e91\",\"lessThan\":\"10e8a2dec9ff1b81de8e892b0850924038adbc6d\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"f3f1c054c288bb6e503005e6d73611151ed20e91\",\"lessThan\":\"a50b4aa3007e63a590d501341f304676ebc74b3b\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"f3f1c054c288bb6e503005e6d73611151ed20e91\",\"lessThan\":\"b9e9ed90b10c82a4e9d4d70a2890f06bfcdd3b78\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"kernel/bpf/hashtab.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4.13\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"4.13\",\"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}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.13\",\"versionEndExcluding\":\"6.6.66\",\"matchCriteriaId\":\"D06EBA07-14CA-4885-B774-9727E64F71C4\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.12.5\",\"matchCriteriaId\":\"9501D045-7A94-42CA-8B03-821BE94A65B7\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/10e8a2dec9ff1b81de8e892b0850924038adbc6d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/a50b4aa3007e63a590d501341f304676ebc74b3b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b9e9ed90b10c82a4e9d4d70a2890f06bfcdd3b78\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2025-11-21T10:42:39+00:00",
      "cve": "CVE-2024-56592",
      "id": "CVE-2024-56592",
      "initial_release_date": "2024-12-27T00:00:00+00:00",
      "product_status:known_affected": "184",
      "product_status:known_not_affected": "14",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: bpf: Call free_htab_elem() after htab_unlock_bucket()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-56592.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-09-02T01:23:38Z",
      "cve": "CVE-2024-56592",
      "id": "CVE-2024-56592",
      "initial_release_date": "2025-01-09T00:22:08Z",
      "product_status:known_affected": "749",
      "product_status:known_not_affected": "170",
      "product_status:recommended": "358",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2024-56592",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-56592.json",
      "version": "57"
    }
  }
}



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…