CVE-2025-39804: lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts
In the Linux kernel, the following vulnerability has been resolved:
lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts
Restore the SIMD usability check that was removed by commit a59e5468a921
("crypto: arm64/poly1305 - Add block-only interface").
This safety check is cheap and is well worth eliminating a footgun.
While the Poly1305 functions should not be called when SIMD registers
are unusable, if they are anyway, they should just do the right thing
instead of corrupting random tasks' registers and/or computing incorrect
MACs. Fixing this is also needed for poly1305_kunit to pass.
Just use may_use_simd() instead of the original crypto_simd_usable(),
since poly1305_kunit won't rely on crypto_simd_disabled_for_test.
Security readout for executives and security teams
Plain-English summary
On ARM64 Linux systems, a Poly1305 cryptographic routine can use SIMD registers when they are unavailable. This may corrupt another task’s register state or calculate incorrect message authentication codes, potentially causing crashes, instability, or authentication failures. The supplied assessment rates it high at CVSS 7.5, but the sources do not establish code execution.
Executive priority
Treat this as an accelerated patching priority for ARM64 Linux fleets, especially production systems relying on kernel cryptography. It is not supported as an all-platform emergency because the issue is architecture-specific and no active exploitation is documented. Potential cross-task register corruption makes delayed remediation undesirable even without confirmed attacks.
Technical view
Commit a59e5468a921 removed a SIMD usability check from the ARM64 Poly1305 implementation. If Poly1305 is called in a no-SIMD context, register corruption or incorrect MAC computation can result. The referenced fixes restore the guard using may_use_simd(). The source specifically identifies ARM64 and notes that the fix is required for poly1305_kunit to pass.
Likely exposure
Exposure is limited to ARM64 Linux kernels containing the a59e5468a921 regression without a referenced fix or equivalent backport. The bundle associates the issue with Linux 6.16 and 6.17-era data, but its flattened version list does not preserve clear range boundaries. Confirm precise status with the kernel or distribution vendor.
Exploitation context
The CVE is not listed in KEV, and the supplied sources provide no evidence of active exploitation, a public exploit, or confirmed remote reachability. Although the CVSS vector uses AV:N, that alone does not prove remote triggerability. Exploitation would depend on a reachable path invoking ARM64 Poly1305 while SIMD registers are unusable.
Researcher notes
The normalized affected-version data is ambiguous: it lists 6.16, 0, 6.16.4, and 6.17 without preserved range operators. Use commit ancestry and vendor backport records for authoritative exposure decisions. No CWE is supplied. The available description establishes unsafe state corruption and incorrect MACs but does not explain a reliable external trigger or security-boundary bypass.
Mitigation direction
Update affected ARM64 systems to a vendor kernel containing either referenced fix or an equivalent backport.
Confirm downstream distribution kernels have backported the SIMD usability check; version numbers alone may be insufficient.
If no corrected package is available, obtain interim mitigation guidance from the kernel or distribution vendor.
Prioritize ARM64 systems using kernel Poly1305 functionality or exposed services that depend heavily on kernel cryptography.
Validation and detection
Inventory kernel versions, architectures, package revisions, and downstream patch status across Linux systems.
Verify patched source includes the may_use_simd() guard or an equivalent vendor backport.
Compare vendor build changelogs against the two referenced kernel commits.
Run the Poly1305 KUnit tests where supported; passing supports, but does not independently prove, remediation.
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-39804 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
0ADP providers
3Source 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.