CVE-2024-56592: Vulnerability in Linux Linux
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---
AI Analysis
Technical Summary
CVE-2024-56592 is a vulnerability identified in the Linux kernel's Berkeley Packet Filter (BPF) subsystem, specifically related to the handling of hash table (htab) elements within BPF maps. The issue arises from improper lock management during the removal and freeing of map elements. When a map is removed from the htab, it may hold the last reference to that map. The function bpf_map_fd_put_ptr() is responsible for freeing the map's ID by invoking bpf_map_free_id(). However, this function is called while holding a bucket lock (raw_spin_lock_t), and bpf_map_free_id() attempts to acquire another lock (map_idr_lock), leading to a lock dependency (lockdep) warning and an invalid wait context bug. This improper locking sequence can cause kernel warnings and potentially lead to deadlocks or race conditions. The root cause is that freeing operations are performed while holding locks that conflict with other locks acquired inside the freeing functions. The fix involves deferring the invocation of freeing functions such as htab_put_fd_value() and free_htab_elem() until after the bucket lock is released. This deferral ensures that locks are not nested in a problematic order, preventing lockdep warnings and invalid wait contexts. The patch also includes careful handling of old map pointers and special fields in the htab elements to avoid premature freeing or reuse issues during batched deletions. The vulnerability affects Linux kernel versions around 6.11.0-rc4+ and involves complex interactions between spinlocks and raw spinlocks in the BPF map management code. No known exploits are reported in the wild at this time, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, this vulnerability primarily threatens the stability and reliability of Linux-based systems that utilize BPF maps extensively, such as those running container orchestration platforms (e.g., Kubernetes), network monitoring tools, or security appliances leveraging eBPF for packet filtering and tracing. The improper lock handling can lead to kernel warnings, potential deadlocks, or race conditions that may cause system crashes or degraded performance. This can result in denial of service (DoS) conditions, impacting critical infrastructure, cloud services, and enterprise environments relying on Linux servers. While the vulnerability does not directly expose confidentiality or integrity risks, the availability impact can be significant, especially in high-availability or real-time systems. Since BPF is widely used for advanced networking and security functions, any instability can disrupt network traffic analysis, firewalling, or observability tools, affecting incident response and operational continuity. The absence of known exploits suggests that exploitation complexity is non-trivial, but the risk remains for sophisticated attackers or accidental system failures triggered by this bug.
Mitigation Recommendations
European organizations should prioritize updating their Linux kernels to versions where this vulnerability is patched, particularly those using kernel versions around 6.11.0-rc4 or similar development releases. System administrators should: 1) Apply official Linux kernel patches addressing CVE-2024-56592 as soon as they become available from trusted sources or distributions. 2) Monitor kernel logs for lockdep warnings or invalid wait context messages that may indicate attempts to trigger this issue or system instability. 3) Limit the use of untrusted or experimental BPF programs that heavily manipulate htab maps until patches are applied. 4) Employ kernel live patching solutions where feasible to reduce downtime during updates. 5) Conduct thorough testing of critical systems after patching to ensure stability and performance are maintained. 6) Implement robust monitoring and alerting on kernel-level errors to detect early signs of exploitation or system faults related to this vulnerability. 7) Collaborate with Linux distribution vendors to receive timely updates and security advisories. These steps go beyond generic advice by focusing on kernel version management, proactive monitoring of kernel lock warnings, and cautious deployment of BPF programs.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Poland, Italy, Spain
CVE-2024-56592: Vulnerability in Linux Linux
Description
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---
AI-Powered Analysis
Technical Analysis
CVE-2024-56592 is a vulnerability identified in the Linux kernel's Berkeley Packet Filter (BPF) subsystem, specifically related to the handling of hash table (htab) elements within BPF maps. The issue arises from improper lock management during the removal and freeing of map elements. When a map is removed from the htab, it may hold the last reference to that map. The function bpf_map_fd_put_ptr() is responsible for freeing the map's ID by invoking bpf_map_free_id(). However, this function is called while holding a bucket lock (raw_spin_lock_t), and bpf_map_free_id() attempts to acquire another lock (map_idr_lock), leading to a lock dependency (lockdep) warning and an invalid wait context bug. This improper locking sequence can cause kernel warnings and potentially lead to deadlocks or race conditions. The root cause is that freeing operations are performed while holding locks that conflict with other locks acquired inside the freeing functions. The fix involves deferring the invocation of freeing functions such as htab_put_fd_value() and free_htab_elem() until after the bucket lock is released. This deferral ensures that locks are not nested in a problematic order, preventing lockdep warnings and invalid wait contexts. The patch also includes careful handling of old map pointers and special fields in the htab elements to avoid premature freeing or reuse issues during batched deletions. The vulnerability affects Linux kernel versions around 6.11.0-rc4+ and involves complex interactions between spinlocks and raw spinlocks in the BPF map management code. No known exploits are reported in the wild at this time, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, this vulnerability primarily threatens the stability and reliability of Linux-based systems that utilize BPF maps extensively, such as those running container orchestration platforms (e.g., Kubernetes), network monitoring tools, or security appliances leveraging eBPF for packet filtering and tracing. The improper lock handling can lead to kernel warnings, potential deadlocks, or race conditions that may cause system crashes or degraded performance. This can result in denial of service (DoS) conditions, impacting critical infrastructure, cloud services, and enterprise environments relying on Linux servers. While the vulnerability does not directly expose confidentiality or integrity risks, the availability impact can be significant, especially in high-availability or real-time systems. Since BPF is widely used for advanced networking and security functions, any instability can disrupt network traffic analysis, firewalling, or observability tools, affecting incident response and operational continuity. The absence of known exploits suggests that exploitation complexity is non-trivial, but the risk remains for sophisticated attackers or accidental system failures triggered by this bug.
Mitigation Recommendations
European organizations should prioritize updating their Linux kernels to versions where this vulnerability is patched, particularly those using kernel versions around 6.11.0-rc4 or similar development releases. System administrators should: 1) Apply official Linux kernel patches addressing CVE-2024-56592 as soon as they become available from trusted sources or distributions. 2) Monitor kernel logs for lockdep warnings or invalid wait context messages that may indicate attempts to trigger this issue or system instability. 3) Limit the use of untrusted or experimental BPF programs that heavily manipulate htab maps until patches are applied. 4) Employ kernel live patching solutions where feasible to reduce downtime during updates. 5) Conduct thorough testing of critical systems after patching to ensure stability and performance are maintained. 6) Implement robust monitoring and alerting on kernel-level errors to detect early signs of exploitation or system faults related to this vulnerability. 7) Collaborate with Linux distribution vendors to receive timely updates and security advisories. These steps go beyond generic advice by focusing on kernel version management, proactive monitoring of kernel lock warnings, and cautious deployment of BPF programs.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-12-27T14:03:06.003Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9823c4522896dcbdf33a
Added to database: 5/21/2025, 9:08:51 AM
Last enriched: 6/28/2025, 12:12:07 PM
Last updated: 8/17/2025, 10:07:29 AM
Views: 16
Related Threats
CVE-2025-41242: Vulnerability in VMware Spring Framework
MediumCVE-2025-47206: CWE-787 in QNAP Systems Inc. File Station 5
HighCVE-2025-5296: CWE-59 Improper Link Resolution Before File Access ('Link Following') in Schneider Electric SESU
HighCVE-2025-6625: CWE-20 Improper Input Validation in Schneider Electric Modicon M340
HighCVE-2025-57703: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in Delta Electronics DIAEnergie
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.