CVE-2024-35994: firmware: qcom: uefisecapp: Fix memory related IO errors and crashes
In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: uefisecapp: Fix memory related IO errors and crashes
It turns out that while the QSEECOM APP_SEND command has specific fields
for request and response buffers, uefisecapp expects them both to be in
a single memory region. Failure to adhere to this has (so far) resulted
in either no response being written to the response buffer (causing an
EIO to be emitted down the line), the SCM call to fail with EINVAL
(i.e., directly from TZ/firmware), or the device to be hard-reset.
While this issue can be triggered deterministically, in the current form
it seems to happen rather sporadically (which is why it has gone
unnoticed during earlier testing). This is likely due to the two
kzalloc() calls (for request and response) being directly after each
other. Which means that those likely return consecutive regions most of
the time, especially when not much else is going on in the system.
Fix this by allocating a single memory region for both request and
response buffers, properly aligning both structs inside it. This
unfortunately also means that the qcom_scm_qseecom_app_send() interface
needs to be restructured, as it should no longer map the DMA regions
separately. Therefore, move the responsibility of DMA allocation (or
mapping) to the caller.
Security readout for executives and security teams
Plain-English summary
A Linux driver bug affecting communication with Qualcomm secure firmware can cause failed operations, input/output errors, or a hard device reset. The supplied CVSS rates it high severity because a low-privileged local attacker may trigger serious impacts. The sources provide no evidence of active exploitation.
Executive priority
Treat this as a high-priority update for affected Qualcomm-based devices, especially operationally important systems where resets could disrupt service. Because exploitation requires local access and no active exploitation is documented, it is not supported as an internet-wide emergency; scope exposure promptly and patch through normal expedited channels.
Technical view
The uefisecapp driver allocated QSEECOM request and response buffers separately, although firmware expects one contiguous memory region. Depending on allocation layout, calls can return no response, fail with EINVAL, or reset the device. The fix uses one properly aligned region and moves DMA allocation or mapping responsibility to the caller.
Likely exposure
Exposure is limited to Linux systems using the Qualcomm uefisecapp/QSEECOM path. The supplied data points to 6.7–6.9-era kernel code, but does not provide reliable package-level boundaries. Distribution backports and device-vendor kernels require individual verification.
Exploitation context
The CVSS vector describes local access, low complexity, low privileges, and no user interaction. The defect can reportedly be triggered deterministically, although failures appeared sporadic during testing. That statement concerns reproducibility, not confirmed malicious exploitation. This CVE is not listed as KEV in the supplied bundle.
Researcher notes
The core invariant is that request and response structures must share one aligned memory region. Consecutive allocations sometimes masked the violation, explaining inconsistent symptoms. The remediation also restructures DMA ownership. The supplied evidence does not establish privilege escalation, demonstrated data compromise, public exploit availability, or exact downstream distribution versions.
Mitigation direction
Install a vendor-supported kernel release incorporating the cited stable fix.
Prioritize Qualcomm-based devices actively using secure-application communication.
Check distribution and device-vendor advisories for backported fixes and exact affected builds.
If no update is available, request a supported workaround from the vendor.
Reduce untrusted local code execution on exposed devices until remediation.
Validation and detection
Inventory Qualcomm-based Linux devices and their exact kernel builds.
Determine whether each system includes and uses the uefisecapp/QSEECOM path.
Compare vendor changelogs or source against CVE-2024-35994 and the cited commits.
Review telemetry for related EIO, EINVAL, secure-call failures, or unexplained resets.
After updating, confirm the running kernel contains the vendor-provided fix.
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-35994 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.
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.