In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
syzkaller started using corpuses where a BPF tracing program deletes
elements from a sockmap/sockhash map. Because BPF tracing programs can be
invoked from any interrupt context, locks taken during a map_delete_elem
operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
is possible, as reported by lockdep:
CPU0 CPU1
---- ----
lock(&htab->buckets[i].lock);
local_irq_disable();
lock(&host->lock);
lock(&htab->buckets[i].lock);
<Interrupt>
lock(&host->lock);
Locks in sockmap are hardirq-unsafe by design. We expects elements to be
deleted from sockmap/sockhash only in task (normal) context with interrupts
enabled, or in softirq context.
Detect when map_delete_elem operation is invoked from a context which is
_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an
error.
Note that map updates are not affected by this issue. BPF verifier does not
allow updating sockmap/sockhash from a BPF tracing program today.
Security readout for executives and security teams
Plain-English summary
CVE-2024-35895 is a Linux kernel BPF sockmap/sockhash issue that can cause a lock inversion deadlock during element deletion. The business risk is availability disruption on affected Linux systems, not confirmed data theft or remote compromise based on the provided sources.
Executive priority
Schedule remediation through normal kernel patch cycles, faster for shared, high-availability, or appliance environments. There is no provided evidence of active exploitation, but a kernel deadlock can still affect service uptime.
Technical view
A BPF tracing program can invoke sockmap/sockhash map_delete_elem from interrupt-sensitive contexts. Sockmap locks are intentionally hardirq-unsafe, so deletion while interrupts are disabled can create a lock inversion deadlock. The kernel fix detects that unsafe context and returns an error instead.
Likely exposure
Exposure is limited to Linux systems running affected kernel builds with BPF sockmap/sockhash functionality reachable. The source lists Linux as affected and provides stable kernel fix commits, but exact distro package exposure requires vendor kernel mapping.
Exploitation context
The source describes syzkaller and lockdep discovery. It does not cite active exploitation, KEV listing, public weaponization, or remote exploitation. Treat this as a kernel availability risk until vendor advisories say otherwise.
Researcher notes
Updates are not affected according to the source because the BPF verifier blocks sockmap/sockhash updates from tracing programs. The fix changes delete behavior by bailing out when called from an unsafe interrupt-disabled context.
Mitigation direction
Update Linux kernels to vendor releases containing the referenced stable fixes.
Check Debian LTS and Siemens advisories if those environments apply.
Prioritize externally exposed or multi-tenant Linux hosts using advanced BPF features.
If no vendor package is available, track vendor guidance before applying custom kernels.
Validation and detection
Inventory Linux kernel versions across production and appliances.
Confirm whether vendor builds include the referenced stable commits.
Review use of BPF tracing, sockmap, or sockhash features on critical hosts.
Check vulnerability scanners against vendor package identifiers, not only upstream versions.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35895 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.