CVE-2025-39869: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: edma: Fix memory allocation size for queue_priority_map
Fix a critical memory allocation bug in edma_setup_from_hw() where
queue_priority_map was allocated with insufficient memory. The code
declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8),
but allocated memory using sizeof(s8) instead of the correct size.
This caused out-of-bounds memory writes when accessing:
queue_priority_map[i][0] = i;
queue_priority_map[i][1] = i;
The bug manifested as kernel crashes with "Oops - undefined instruction"
on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the
memory corruption triggered kernel hardening features on Clang.
Change the allocation to use sizeof(*queue_priority_map) which
automatically gets the correct size for the 2D array structure.
Security readout for executives and security teams
Plain-English summary
A size-calculation error in the Linux TI EDMA driver can corrupt kernel memory while the driver starts. The documented result is a kernel crash on an ARM BeagleBoard-X15. Systems not using the affected EDMA driver and hardware are less likely to be exposed.
Executive priority
Treat this as high priority for embedded or ARM systems using TI EDMA because kernel memory corruption can cause outages. For other Linux fleets, rapidly establish hardware and driver exposure before scheduling remediation. Current evidence supports urgent patching of exposed systems, not an enterprise-wide emergency response.
Technical view
edma_setup_from_hw() allocated each queue_priority_map element using sizeof(s8), although each element contains two s8 values. Initializing both values therefore wrote beyond the allocation. The upstream correction uses sizeof(*queue_priority_map), matching the declared two-element array and preventing the out-of-bounds writes.
Likely exposure
Exposure is concentrated in Linux systems containing the vulnerable TI EDMA driver code where compatible hardware causes the driver to probe. Embedded and ARM deployments deserve particular review. The supplied version data is not sufficiently clear for reliable version-only decisions; confirm distribution backports and the relevant fix commit.
Exploitation context
The CVSS 3.1 score is 8.4 with a local attack vector. The bundle reports memory corruption and kernel crashes during driver probing, but provides no evidence of active exploitation, public weaponization, or demonstrated code execution. This CVE is not identified as CISA KEV in the supplied data.
Researcher notes
The demonstrated behavior is an allocation underrun followed by deterministic out-of-bounds initialization writes during probe. The source bundle documents a crash under Clang hardening, but does not establish confidentiality loss, integrity compromise, privilege escalation, or controlled execution. Distribution-specific affected and fixed versions require separate vendor confirmation.
Mitigation direction
Install a vendor-supported kernel containing the queue_priority_map allocation fix or an equivalent distribution backport.
Prioritize updates on systems using TI EDMA-compatible hardware or loading the affected driver.
If updating is delayed, consult the operating-system vendor for supported temporary mitigations.
Reboot into the corrected kernel and remove vulnerable kernel packages according to vendor guidance.
Validation and detection
Record the running kernel version and compare its changelog with vendor CVE guidance and referenced fixes.
Confirm whether TI EDMA-compatible hardware exists and whether the associated driver probes during startup.
Review kernel logs for EDMA probe failures, memory-corruption reports, or “Oops - undefined instruction” crashes.
Verify the installed kernel includes the sizeof(*queue_priority_map) correction or an equivalent backport.
After updating, reboot and confirm the EDMA driver initializes without kernel faults.
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-2025-39869 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.
1CVSS vectors
3Timeline events
1ADP providers
10Source links
CVSS vector scores
1 official score
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.