{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-26670 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-26670 is a medium-severity vulnerability in Linux kernel, published on 2 Apr 2024. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2024-26670 and fix it if it is affected.\n\nWhat it is: CVE-2024-26670 is a medium-severity vulnerability in Linux kernel, published on 2 Apr 2024. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2024-26670 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2024-26670/ (Markdown: https://insights.sbomify.com/CVE-2024-26670/index.md)","id":"CVE-2024-26670","markdown":"https://insights.sbomify.com/CVE-2024-26670/index.md","name":"CVE-2024-26670","record":{"aliases":["BELL-CVE-2024-26670","DEBIAN-CVE-2024-26670","GHSA-vpp3-8c88-m6w7","ROOT-OS-DEBIAN-12-CVE-2024-26670","UBUNTU-CVE-2024-26670"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["data_read","privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"Incorrect placement of speculative load workaround in Linux kernel allows potential information disclosure or privilege escalation on affected ARM cores.","user_interaction":"not_required","vuln_class":"other"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"cisa-adp","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-787","name":"Out-of-bounds Write"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD\n\nCurrently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround isn't\nquite right, as it is supposed to be applied after the last explicit\nmemory access, but is immediately followed by an LDR.\n\nThe ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used to\nhandle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295,\nwhich are described in:\n\n* https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en\n* https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en\n\nIn both cases the workaround is described as:\n\n| If pagetable isolation is disabled, the context switch logic in the\n| kernel can be updated to execute the following sequence on affected\n| cores before exiting to EL0, and after all explicit memory accesses:\n|\n| 1. A non-shareable TLBI to any context and/or address, including\n|    unused contexts or addresses, such as a `TLBI VALE1 Xzr`.\n|\n| 2. A DSB NSH to guarantee completion of the TLBI.\n\nThe important part being that the TLBI+DSB must be placed \"after all\nexplicit memory accesses\".\n\nUnfortunately, as-implemented, the TLBI+DSB is immediately followed by\nan LDR, as we have:\n\n| alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD\n| \ttlbi\tvale1, xzr\n| \tdsb\tnsh\n| alternative_else_nop_endif\n| alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0\n| \tldr\tlr, [sp, #S_LR]\n| \tadd\tsp, sp, #PT_REGS_SIZE\t\t// restore sp\n| \teret\n| alternative_else_nop_endif\n|\n| [ ... KPTI exception return path ... ]\n\nThis patch fixes this by reworking the logic to place the TLBI+DSB\nimmediately before the ERET, after all explicit memory accesses.\n\nThe ERET is currently in a separate alternative block, and alternatives\ncannot be nested. To account for this, the alternative block for\nARM64_UNMAP_KERNEL_AT_EL0 is replaced with a single alternative branch\nto skip the KPTI logic, with the new shape of the logic being:\n\n| alternative_insn \"b .L_skip_tramp_exit_\\@\", nop, ARM64_UNMAP_KERNEL_AT_EL0\n| \t[ ... KPTI exception return path ... ]\n| .L_skip_tramp_exit_\\@:\n|\n| \tldr\tlr, [sp, #S_LR]\n| \tadd\tsp, sp, #PT_REGS_SIZE\t\t// restore sp\n|\n| alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD\n| \ttlbi\tvale1, xzr\n| \tdsb\tnsh\n| alternative_else_nop_endif\n| \teret\n\nThe new structure means that the workaround is only applied when KPTI is\nnot in use; this is fine as noted in the documented implications of the\nerratum:\n\n| Pagetable isolation between EL0 and higher level ELs prevents the\n| issue from occurring.\n\n... and as per the workaround description quoted above, the workaround\nis only necessary \"If pagetable isolation is disabled\".","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD","id":"CVE-2024-26670","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"other","year":"2024"},"n_packages":0,"n_references":3,"next":{"headline":"blk-mq: fix IO hang from sbitmap wakeup race","id":"CVE-2024-26671"},"packages":[],"prev":{"headline":"net/sched: flower: Fix chain template offload","id":"CVE-2024-26669"},"products":["Linux"],"published":"2024-04-02","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-05-23","vendors":["Linux"]},"summary":"Incorrect placement of speculative load workaround in Linux kernel allows potential information disclosure or privilege escalation on affected ARM cores.","url":"https://insights.sbomify.com/CVE-2024-26670/"}