CVE-2024-26670: arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD

Published Apr 2, 2024
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

arm64: entry: fix ARM64WORKAROUNDSPECULATIVEUNPRIVLOAD

Currently the ARM64WORKAROUNDSPECULATIVEUNPRIVLOAD workaround isn't quite right, as it is supposed to be applied after the last explicit memory access, but is immediately followed by an LDR.

The ARM64WORKAROUNDSPECULATIVEUNPRIVLOAD workaround is used to handle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295, which are described in:

https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en

In both cases the workaround is described as:

| If pagetable isolation is disabled, the context switch logic in the | kernel can be updated to execute the following sequence on affected | cores before exiting to EL0, and after all explicit memory accesses: | | 1. A non-shareable TLBI to any context and/or address, including | unused contexts or addresses, such as a TLBI VALE1 Xzr. | | 2. A DSB NSH to guarantee completion of the TLBI.

The important part being that the TLBI+DSB must be placed "after all explicit memory accesses".

Unfortunately, as-implemented, the TLBI+DSB is immediately followed by an LDR, as we have:

| alternativeif ARM64WORKAROUNDSPECULATIVEUNPRIVLOAD | tlbi vale1, xzr | dsb nsh | alternativeelsenopendif | alternativeifnot ARM64UNMAPKERNELATEL0 | ldr lr, [sp, #SLR] | add sp, sp, #PTREGSSIZE // restore sp | eret | alternativeelsenopendif | | [ ... KPTI exception return path ... ]

This patch fixes this by reworking the logic to place the TLBI+DSB immediately before the ERET, after all explicit memory accesses.

The ERET is currently in a separate alternative block, and alternatives cannot be nested. To account for this, the alternative block for ARM64UNMAPKERNELATEL0 is replaced with a single alternative branch to skip the KPTI logic, with the new shape of the logic being:

| alternativeinsn "b .Lskiptrampexit\@", nop, ARM64UNMAPKERNELATEL0 | [ ... KPTI exception return path ... ] | .Lskiptrampexit\@: | | ldr lr, [sp, #SLR] | add sp, sp, #PTREGSSIZE // restore sp | | alternativeif ARM64WORKAROUNDSPECULATIVEUNPRIVLOAD | tlbi vale1, xzr | dsb nsh | alternativeelsenopendif | eret

The new structure means that the workaround is only applied when KPTI is not in use; this is fine as noted in the documented implications of the erratum:

| Pagetable isolation between EL0 and higher level ELs prevents the | issue from occurring.

... and as per the workaround description quoted above, the workaround is only necessary "If pagetable isolation is disabled".

Other sources

In the Linux kernel, the following vulnerability has been resolved:

arm64: entry: fix ARM64WORKAROUNDSPECULATIVEUNPRIVLOAD

The Linux kernel CVE team has assigned CVE-2024-26670 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040238-CVE-2024-26670-ecbd@gregkh/T

— Red Hat

Affected Software

12 affected componentsFixes available
redhat/kernel<6.6.15
6.6.15
redhat/kernel<6.7.3
6.7.3
redhat/kernel<6.8
6.8
Linux Linux kernel>=6.6<6.6.15
Linux Linux kernel>=6.7<6.7.3
debian/linux*
debian/linux<6.6.15-1
6.6.15-1
debian/linux<6.6.15-1
6.6.15-1
linux/kernel<6.1.191
6.1.191
linux/kernel>=6.2.0<6.6.15
6.6.15
linux/kernel>=6.6.0<6.7.3
6.7.3
debian/linux<=6.1.176-1, <=6.1.190-1
6.12.107-16.12.115-27.2.12-17.2.15-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade redhat/kernel to a version that resolves this vulnerability.

    Fixed in 6.6.15
  2. Upgrade

    Upgrade redhat/kernel to a version that resolves this vulnerability.

    Fixed in 6.7.3
  3. Upgrade

    Upgrade redhat/kernel to a version that resolves this vulnerability.

    Fixed in 6.8
  4. Upgrade

    Upgrade debian/linux to a version that resolves this vulnerability.

    Fixed in 6.6.15-1
  5. Upgrade

    Upgrade debian/linux to a version that resolves this vulnerability.

    Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.14-1
  6. Upgrade

    Upgrade linux/Kernel to a version that resolves this vulnerability.

    Fixed in 6.1.191
  7. Upgrade

    Upgrade linux/Kernel to a version that resolves this vulnerability.

    Fixed in 6.6.15
  8. Upgrade

    Upgrade linux/Kernel to a version that resolves this vulnerability.

    Fixed in 6.7.3

Event History

Apr 2, 2024
CVE Published
via MITRE·06:43 AM
Data Sourced
via MITRE·06:43 AM
Description
Data Sourced
via OSV·06:43 AM
DescriptionSeverityAffected Software
Data Sourced
via NVD·07:15 AM
RemedyDescriptionSeverityWeaknessAffected Software
Data Sourced
via Red Hat·11:25 PM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2024-26670?

The severity of CVE-2024-26670 has not been explicitly classified, but it affects critical components of the Linux kernel.

2

Which versions of the kernel are affected by CVE-2024-26670?

CVE-2024-26670 affects various versions of the Linux kernel including up to 6.6.15, 6.7.3, and specific versions within the 5.x range.

3

How do I fix CVE-2024-26670?

To fix CVE-2024-26670, update the Linux kernel to versions 6.6.15, 6.7.3, or 6.8 for Red Hat, or the specified versions for Debian.

4

Is there a workaround for CVE-2024-26670?

Currently, the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is implemented but requires a correct application after memory access.

5

What components of the Linux kernel does CVE-2024-26670 affect?

CVE-2024-26670 specifically impacts the ARM64 architecture handling within the Linux kernel.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203