CVE-2024-44949: parisc: fix a possible DMA corruption
In the Linux kernel, the following vulnerability has been resolved:
parisc: fix a possible DMA corruption
ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be
possible that two unrelated 16-byte allocations share a cache line. If
one of these allocations is written using DMA and the other is written
using cached write, the value that was written with DMA may be
corrupted.
This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -
that's the largest possible cache line size.
As different parisc microarchitectures have different cache line size, we
define arch_slab_minalign(), cache_line_size() and
dma_get_cache_alignment() so that the kernel may tune slab cache
parameters dynamically, based on the detected cache line size.
Security readout for executives and security teams
Plain-English summary
A Linux kernel memory-alignment flaw on PA-RISC systems can let normal processor writes corrupt data written by DMA when separate allocations share a cache line. Corruption could affect confidentiality, integrity, or availability, but the supplied evidence limits the issue to PA-RISC and does not show active exploitation.
Executive priority
Treat confirmed affected PA-RISC systems as a high, targeted remediation priority because silent memory corruption can undermine system trust. Estate-wide urgency is lower where PA-RISC is absent. Request architecture inventory and vendor-confirmed patch status rather than assuming all Linux systems are exposed.
Technical view
On parisc, ARCH_DMA_MINALIGN was 16 bytes, below possible cache-line sizes. Unrelated allocations could therefore share a line, allowing cached writes to overwrite DMA-written data. The fix sets alignment to 128 bytes on PA20 and 32 bytes on PA1.1, with runtime cache-alignment helpers.
Likely exposure
Exposure appears limited to Linux systems using PA-RISC hardware and affected kernel code. Other architectures are not identified. The supplied affected-version data contains ambiguous entries and commit hashes, so organizations should confirm applicability using kernel provenance and vendor advisories.
Exploitation context
CVSS 3.1 scores this 7.8, requiring local access and low privileges without user interaction. CISA KEV status is false, and the supplied sources provide no evidence of active exploitation or a public exploit. Practical exploitation conditions are not established.
Researcher notes
The failure involves cache-line aliasing between unrelated allocations and DMA coherency, not a described remote entry point. Exact vulnerable and fixed release boundaries cannot be resolved confidently from the supplied version list. Validate through architecture-specific source history and vendor backport records; avoid inferring exploitability from CVSS alone.
Mitigation direction
Upgrade to a vendor-supported kernel containing the applicable referenced stable fix.
Confirm distribution remediation guidance before selecting a target kernel release.
Prioritize PA-RISC systems performing DMA or processing sensitive workloads.
If upgrading is delayed, consult the vendor; no standalone workaround is specified.
Validation and detection
Inventory Linux hosts and identify any using the PA-RISC architecture.
Record kernel versions, distribution packages, and source commit provenance.
Check whether the applicable referenced stable commit is incorporated.
Verify the running kernel after remediation, including following any required reboot.
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-44949 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.