CVE-2024-46829: rtmutex: Drop rt_mutex::wait_lock before scheduling
In the Linux kernel, the following vulnerability has been resolved:
rtmutex: Drop rt_mutex::wait_lock before scheduling
rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the
good case it returns with the lock held and in the deadlock case it emits a
warning and goes into an endless scheduling loop with the lock held, which
triggers the 'scheduling in atomic' warning.
Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning
and dropping into the schedule for ever loop.
[ tglx: Moved unlock before the WARN(), removed the pointless comment,
massaged changelog, added Fixes tag ]
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel bug in real-time mutex deadlock handling. In a deadlock path, the kernel could keep an internal lock held while scheduling, producing a kernel warning and potentially affecting system stability. The source bundle does not provide CVSS, CWE, or confirmed exploitation evidence.
Executive priority
Prioritize normal kernel security maintenance unless local context shows unstable real-time workloads or exposed critical infrastructure. There is no cited active exploitation or severity score, but kernel reliability bugs can still create operational risk.
Technical view
rt_mutex_handle_deadlock() is called while rt_mutex::wait_lock is held. In the deadlock case, it warned and entered an endless schedule loop without dropping the lock, triggering a scheduling-in-atomic warning. Stable kernel commits change this path to unlock before warning and scheduling.
Likely exposure
Exposure is limited to Linux systems running affected kernel versions or vendor kernels without the stable backport. The bundle lists affected Linux version entries including 3.16, 4.19.322, 5.4.284, 5.10.226, 5.15.167, 6.1.110, 6.6.51, 6.10.10, and 6.11.
Exploitation context
The bundle marks KEV as false and cites no active exploitation. It also does not describe attacker prerequisites, exploitability, or impact beyond the kernel deadlock warning behavior. Treat exploitation status as unconfirmed, not active.
Researcher notes
The public record gives a narrow kernel locking defect and fix rationale, but lacks CVSS, CWE, exploit prerequisites, and concrete impact classification. Validation should focus on kernel source/package backport evidence, not only reported version strings.
Mitigation direction
Inventory Linux kernel versions across servers, appliances, and container hosts.
Apply kernel updates that include the referenced upstream stable commits.
For Debian systems, review the referenced Debian LTS advisories and install security updates.
Check distribution vendor guidance for backported fixes before relying on upstream version numbers.
Validation and detection
Compare running kernel builds against vendor advisories and package changelogs.
Confirm the relevant stable commit is present in custom or self-built kernels.
Verify patched systems rebooted into the updated kernel.
Monitor kernel logs for related rtmutex or scheduling-in-atomic warnings.
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-46829 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.