CVE-2024-58042: rhashtable: Fix potential deadlock by moving schedule_work outside lock
In the Linux kernel, the following vulnerability has been resolved:
rhashtable: Fix potential deadlock by moving schedule_work outside lock
Move the hash table growth check and work scheduling outside the
rht lock to prevent a possible circular locking dependency.
The original implementation could trigger a lockdep warning due to
a potential deadlock scenario involving nested locks between
rhashtable bucket, rq lock, and dsq lock. By relocating the
growth check and work scheduling after releasing the rth lock, we break
this potential deadlock chain.
This change expands the flexibility of rhashtable by removing
restrictive locking that previously limited its use in scheduler
and workqueue contexts.
Import to say that this calls rht_grow_above_75(), which reads from
struct rhashtable without holding the lock, if this is a problem, we can
move the check to the lock, and schedule the workqueue after the lock.
Modified so that atomic_inc is also moved outside of the bucket
lock along with the growth above 75% check.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can cause a deadlock in rhashtable handling, potentially making affected systems unavailable. It requires local, low-privileged access and does not expose data or allow direct tampering. The main business concern is service disruption on systems running affected Linux kernel versions.
Executive priority
Treat as a normal-priority kernel availability fix unless affected systems support critical shared workloads or untrusted local users. There is no source evidence of active exploitation, remote access, data theft, or integrity compromise.
Technical view
The flaw is a CWE-667 improper locking issue in Linux rhashtable code. Scheduling hash table growth work while holding the rht lock could create a circular locking dependency involving rhashtable bucket, runqueue, and dsq locks. The fix moves growth checks, work scheduling, and atomic increment behavior outside the bucket lock.
Likely exposure
Exposure is most relevant for Linux hosts using affected kernel builds in the 6.12, 6.13, or 6.14 lines or kernels derived from the cited vulnerable commit. The source bundle does not identify specific distributions, appliances, or managed services.
Exploitation context
The CVSS vector requires local access with low privileges and no user interaction. CISA KEV status is false in the bundle, and no cited source claims active exploitation. Impact is availability only, with high potential availability impact if triggered.
Researcher notes
The evidence points to a locking-order deadlock risk, not a memory corruption or privilege escalation issue. Version evidence in the bundle is limited, so researchers should rely on upstream commit references and vendor backport status for precise exposure decisions.
Mitigation direction
Check vendor kernel advisories for packages containing the cited stable fixes.
Prioritize kernel updates on multi-user or workload-dense Linux systems.
Track distribution backports rather than relying only on upstream version numbers.
Use standard maintenance windows for reboot-required kernel updates.
If patching is delayed, reduce local untrusted shell access where practical.
Validation and detection
Inventory Linux kernel versions across servers, containers hosts, and appliances.
Compare running kernels with vendor advisories and the cited upstream fixes.
Confirm whether distributions have backported the stable kernel commits.
Review monitoring for kernel lockups or unexplained host availability events.
Document any affected systems that cannot be patched promptly.
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.
cwe · low confidence lookup
CWE-667: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-667 · source CWE mapping
Improper Locking
Improper Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.