CVE-2024-35819: soc: fsl: qbman: Use raw spinlock for cgr_lock
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on
PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until
commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")
which invokes smp_call_function_single via qman_update_cgr_safe every
time a link goes up or down.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel concurrency bug in the Freescale/NXP QBMan networking support. On real-time kernels, code triggered during network link up or down could use a sleeping spinlock in hard interrupt context. The public record does not provide a CVSS score or confirmed impact beyond kernel correctness and stability risk.
Executive priority
Handle as targeted kernel maintenance, not an emergency internet-wide issue based on current evidence. Prioritize affected embedded, edge, or network appliances running relevant Freescale/NXP networking hardware, especially where uptime or real-time behavior matters.
Technical view
The issue is in soc:fsl:qbman cgr_lock handling. smp_call_function callbacks run in hard IRQ context, including on PREEMPT_RT, where regular spinlocks may sleep. The fix changes cgr_lock to a raw spinlock. The bug became apparent after DPAA queue-depth updates called qman_update_cgr_safe on link state changes.
Likely exposure
Exposure appears limited to Linux systems using the affected Freescale/NXP QBMan or DPAA networking path, especially PREEMPT_RT configurations. General Linux servers without that hardware or driver path are less likely exposed, but kernel package provenance should decide final scope.
Exploitation context
The source bundle does not show CISA KEV listing, public exploitation, exploit availability, or a remote attack path. The trigger described is operational: link up or down events invoking the affected code path. Treat exploitation status as unconfirmed.
Researcher notes
Key evidence is the kernel fix rationale, not a detailed vulnerability analysis. No CWE, CVSS, or exploit details are present in the bundle. Validation should focus on kernel configuration, driver reachability, affected stable branch mapping, and distro package status.
Mitigation direction
Update to a vendor kernel containing the referenced stable fix.
Check Debian LTS advisories if using Debian-packaged kernels.
Prioritize PREEMPT_RT systems using Freescale/NXP DPAA or QBMan networking.
Follow your distribution vendor guidance for exact fixed package versions.
Validation and detection
Inventory kernels and hardware using Freescale/NXP DPAA or QBMan drivers.
Check whether PREEMPT_RT is enabled on exposed systems.
Compare installed kernel versions against vendor advisories and stable commits.
Review network link flap incidents for kernel warnings or lockup symptoms.
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-35819 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.