Compare commits

...

16 Commits

Author SHA1 Message Date
Stéphane Lesimple
75d053a0f1 fix: add rebleet to --variant 2026-04-04 18:21:33 +02:00
Stéphane Lesimple
cccb3c0081 enh: add known fixed ucode versions for CVE-2023-23583 (Reptar) and CVE-2024-45332 (BPI) 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
090f109c52 doc: add CVE-2023-31315 (SinkClose) to the unsupported list, add categories 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
5dc9c3c18d chore: reorder CVE list in README.md 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
a00fab131f feat: implement CVE-2025-40300 (VMScape) and CVE-2024-45332 (BTI) 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
e0b818f8fa chore: stalebot: disable dryrun by default 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
4af11551ba feat: implement CVE-2024-28956 (ITS, Indirect Target Selection) vulnerability and mitigation detection 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
dfed6f35c5 doc: add note about more unsupported CVEs
CVE-2020-12965 - Transient Execution of Non-Canonical Accesses (SLAM)
CVE-2024-7881 - ARM Prefetcher Privilege Escalation
CVE-2024-56161 - EntrySign (AMD Microcode Signature Bypass)
CVE-2025-20623 - Shared Microarchitectural Predictor State (10th Gen Intel)
CVE-2025-24495 - Lion Cove BPU Initialization
CVE-2025-29943 - StackWarp (AMD SEV-SNP)
2026-04-04 16:07:12 +00:00
Stéphane Lesimple
1652977f47 add a generated version of src/libs/003_intel_models.sh 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
a089ae8cef fix: sys_interface_check() must set the caller's $msg var (closes #533) 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
cc6bbaad19 chore: don't include src/ generated files in build 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
2717b0a4be doc: CVE-2020-12965 unsupported (#478) 2026-04-04 16:07:12 +00:00
Stéphane Lesimple
6fac2d8ff1 Merge pull request #532 from speed47/test
Retbleed / Downfall overhald / doc updates
2026-04-02 21:32:39 +00:00
Stéphane Lesimple
d3c0f1a24d Merge pull request #530 from speed47/test
chore: workflows revamp
2026-04-02 16:49:41 +00:00
Stéphane Lesimple
952fe6a87f Merge branch 'test' into source 2026-04-02 18:40:05 +02:00
Stéphane Lesimple
afadf53f7f chore: add stalebot in dryrun 2026-04-02 11:15:36 +00:00
15 changed files with 899 additions and 60 deletions

View File

@@ -98,6 +98,7 @@ jobs:
git fetch origin ${{ github.ref_name }}-build
git checkout -f ${{ github.ref_name }}-build
mv $tmpdir/* .
rm -rf src/
mkdir -p .github
rsync -vaP --delete $tmpdir/.github/ .github/
git add --all

View File

@@ -1 +1 @@
23
26

View File

@@ -30,4 +30,4 @@ jobs:
days-before-close: 7
stale-issue-label: stale
remove-stale-when-updated: true
debug-only: ${{ case(inputs.action == 'apply', false, true) }}
debug-only: ${{ case(inputs.action == 'dryrun', true, false) }}

View File

@@ -123,10 +123,12 @@ It must always be okay to run this script in a production environment.
Never look at the kernel version string to determine whether it supports a mitigation. This would defeat the script's purpose: it must detect mitigations in unknown, vendor-patched, or backported kernels. Similarly, do not blindly trust what `sysfs` reports when it is possible to verify directly.
### 3. Never hardcode microcode versions
### 3. Never hardcode microcode versions (with one exception)
Never look at the microcode version to determine whether it has the proper mitigation mechanisms. Instead, probe for the mechanisms themselves (CPUID bits, MSR values), as the kernel would.
**Exception**: When a vulnerability is fixed purely by a microcode update and the fix exposes **no** detectable CPUID bit, MSR bit, or ARCH\_CAP flag, then we must hardcode the known-fixing microcode versions for each affected CPU stepping. In this case, build a `<vuln>_ucode_list` table of `FF-MM-SS/platformid_mask,fixed_ucode_version` tuples (sourced from the Intel affected processor list and the Intel-Linux-Processor-Microcode-Data-Files release notes), match against `cpu_cpuid` + `cpu_platformid` in `is_cpu_affected()`, and store the required version in a `g_<vuln>_fixed_ucode_version` global. The CVE check then compares `cpu_ucode` against this threshold. Because Intel never lists EOL CPUs, the microcode list may be incomplete: keep a model blacklist as a fallback so that affected CPUs without a known fix are still flagged as affected (the CVE check should handle the empty `g_<vuln>_fixed_ucode_version` case by reporting VULN with "no microcode update available"). See Reptar (`g_reptar_fixed_ucode_version`) and BPI (`g_bpi_fixed_ucode_version`) for reference implementations.
### 4. Assume affected unless proven otherwise (whitelist approach)
When a CPU is not explicitly known to be unaffected by a vulnerability, assume that it is affected. This conservative default has been the right call since the early Spectre/Meltdown days and remains sound.
@@ -705,12 +707,12 @@ CVEs that need VMM context should call `check_has_vmm` early in their `_linux()`
### Key Rules to Remember
- **Never hardcode kernel or microcode versions** - detect capabilities directly (design principles 2 and 3).
- **Never hardcode kernel or microcode versions** - detect capabilities directly (design principles 2 and 3). Exception: when a microcode fix has no detectable indicator, hardcode fixing versions per CPU (see principle 3).
- **Assume affected by default** - only mark a CPU as unaffected when there is positive evidence (design principle 4).
- **Always handle both live and offline modes** - use `$opt_live` to branch, and print `N/A "not testable in offline mode"` for runtime-only checks when offline.
- **Use `explain()`** when reporting VULN to give actionable remediation advice (see "Cross-Cutting Features" above).
- **Handle `--paranoid` and `--vmm`** when the CVE has stricter mitigation tiers or VMM-specific aspects (see "Cross-Cutting Features" above).
- **All indentation must use tabs** (CI enforces this).
- **All indentation must use 4 spaces** (CI enforces this via `fmt-check`; the vim modeline `et` enables expandtab).
- **Stay POSIX-compatible** - no bashisms, no GNU-only flags in portable code paths.
## Function documentation headers

View File

@@ -2,6 +2,81 @@
This document lists transient execution CVEs that have been evaluated and determined to be **out of scope** for this tool. See the [Which rules are governing the support of a CVE in this tool?](dist/FAQ.md#which-rules-are-governing-the-support-of-a-cve-in-this-tool) section in the FAQ for the general policy.
CVEs are grouped by reason for exclusion:
- [Already covered by an existing CVE check](#already-covered-by-an-existing-cve-check) — subvariants or subsets whose mitigations are already detected under a parent CVE.
- [No kernel or microcode mitigations to check](#no-kernel-or-microcode-mitigations-to-check) — no fix has been issued, or the mitigation is not detectable by this tool.
- [Not a transient/speculative execution vulnerability](#not-a-transientspeculative-execution-vulnerability) — wrong vulnerability class entirely.
---
# Already covered by an existing CVE check
These CVEs are subvariants or subsets of vulnerabilities already implemented in the tool. Their mitigations are detected as part of the parent CVE's checks.
## CVE-2018-3693 — Bounds Check Bypass Store (Spectre v1.1)
- **Issue:** [#236](https://github.com/speed47/spectre-meltdown-checker/issues/236)
- **Red Hat advisory:** [Speculative Store Bypass / Bounds Check Bypass (CVE-2018-3693)](https://access.redhat.com/solutions/3523601)
- **CVSS:** 5.6 (Medium)
- **Covered by:** CVE-2017-5753 (Spectre V1)
A subvariant of Spectre V1 where speculative store operations can write beyond validated buffer boundaries before the bounds check resolves, allowing an attacker to alter cache state and leak information via side channels.
**Why out of scope:** The mitigations are identical to CVE-2017-5753 (Spectre V1): `lfence` instructions after bounds checks and `array_index_nospec()` barriers in kernel code. There is no separate sysfs entry, no new CPU feature flag, and no distinct microcode change. This tool's existing CVE-2017-5753 checks already detect these mitigations (`__user pointer sanitization`, `usercopy/swapgs barriers`), so CVE-2018-3693 is fully covered as part of Spectre V1.
## CVE-2018-15572 — SpectreRSB (Return Stack Buffer)
- **Issue:** [#224](https://github.com/speed47/spectre-meltdown-checker/issues/224)
- **Research paper:** [Spectre Returns! Speculation Attacks using the Return Stack Buffer (WOOT'18)](https://arxiv.org/abs/1807.07940)
- **Kernel fix:** [commit fdf82a7856b3](https://github.com/torvalds/linux/commit/fdf82a7856b32d905c39afc85e34364491e46346) (Linux 4.18.1)
- **CVSS:** 6.5 (Medium)
- **Covered by:** CVE-2017-5715 (Spectre V2)
The `spectre_v2_select_mitigation` function in the Linux kernel before 4.18.1 did not always fill the RSB upon a context switch, allowing userspace-to-userspace SpectreRSB attacks on Skylake+ CPUs where an empty RSB falls back to the BTB.
**Why out of scope:** This CVE is a Spectre V2 mitigation gap (missing RSB filling on context switch), not a distinct hardware vulnerability. It is already fully covered by this tool's CVE-2017-5715 (Spectre V2) checks, which detect whether the kernel performs RSB filling on CPUs vulnerable to RSB underflow (Skylake+ and RSBA-capable CPUs). A missing RSB fill is flagged as a caveat ("RSB filling missing on Skylake+") in the Spectre V2 verdict.
## CVE-2019-1125 — Spectre SWAPGS gadget
- **Issue:** [#301](https://github.com/speed47/spectre-meltdown-checker/issues/301)
- **Kernel fix:** [commit 18ec54fdd6d1](https://github.com/torvalds/linux/commit/18ec54fdd6d18d92025af097cd042a75cf0ea24c) (Linux 5.3)
- **CVSS:** 5.6 (Medium)
- **Covered by:** CVE-2017-5753 (Spectre V1)
A Spectre V1 subvariant where the `SWAPGS` instruction can be speculatively executed on x86 CPUs, allowing an attacker to leak kernel memory via a side channel on the GS segment base value.
**Why out of scope:** This is a Spectre V1 subvariant whose mitigation (SWAPGS barriers) shares the same sysfs entry as CVE-2017-5753. This tool's existing CVE-2017-5753 checks already detect SWAPGS barriers: a mitigated kernel reports `"Mitigation: usercopy/swapgs barriers and __user pointer sanitization"`, while a kernel lacking the fix reports `"Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers"`. CVE-2019-1125 is therefore fully covered as part of Spectre V1.
## CVE-2025-20623 — Shared Microarchitectural Predictor State (10th Gen Intel)
- **Advisory:** [INTEL-SA-01247](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01247.html)
- **Affected CPUs:** Intel 10th Generation Core Processors only
- **CVSS:** 5.6 (Medium)
- **Covered by:** CVE-2024-45332 (BPI)
Shared microarchitectural predictor state on 10th generation Intel CPUs may allow information disclosure.
**Why out of scope:** Very narrow scope (single CPU generation). Mitigated by the same microcode update as CVE-2024-45332 (BPI) and handled through the existing Spectre V2 framework. No dedicated sysfs entry or kernel mitigation beyond what BPI already provides.
## CVE-2025-24495 — Lion Cove BPU Initialization
- **Advisory:** [INTEL-SA-01322](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01322.html)
- **Research:** [Training Solo (VUSec)](https://www.vusec.net/projects/training-solo/)
- **Affected CPUs:** Intel Core Ultra with Lion Cove core only (Lunar Lake, Arrow Lake)
- **CVSS:** 6.8 (Medium, CVSS v4)
- **Covered by:** CVE-2024-28956 (ITS)
A branch predictor initialization issue specific to Intel's Lion Cove microarchitecture, discovered as part of the "Training Solo" research.
**Why out of scope:** This is a subset of the ITS (Indirect Target Selection) vulnerability (CVE-2024-28956). It shares the same sysfs entry (`/sys/devices/system/cpu/vulnerabilities/indirect_target_selection`) and kernel mitigation framework. Since ITS (CVE-2024-28956) is implemented in this tool, Lion Cove BPU is already covered automatically.
---
# No kernel or microcode mitigations to check
These CVEs are real vulnerabilities, but no kernel or microcode fix has been issued, the mitigation is delegated to individual software, or the fix is not detectable by this tool.
## CVE-2018-9056 — BranchScope
- **Issue:** [#169](https://github.com/speed47/spectre-meltdown-checker/issues/169)
@@ -13,39 +88,6 @@ A speculative execution attack exploiting the directional branch predictor, allo
**Why out of scope:** No kernel or microcode mitigations have been issued. Red Hat closed their tracking bug as "CLOSED CANTFIX", concluding that "this is a hardware processor issue, not a Linux kernel flaw" and that "it is specific to a target software which uses sensitive information in branching expressions." The mitigation responsibility falls on individual software to avoid using sensitive data in conditional branches, which is out of the scope of this tool.
## CVE-2018-3693 — Bounds Check Bypass Store (Spectre v1.1)
- **Issue:** [#236](https://github.com/speed47/spectre-meltdown-checker/issues/236)
- **Red Hat advisory:** [Speculative Store Bypass / Bounds Check Bypass (CVE-2018-3693)](https://access.redhat.com/solutions/3523601)
- **CVSS:** 5.6 (Medium)
A subvariant of Spectre V1 where speculative store operations can write beyond validated buffer boundaries before the bounds check resolves, allowing an attacker to alter cache state and leak information via side channels.
**Why out of scope:** The mitigations are identical to CVE-2017-5753 (Spectre V1): `lfence` instructions after bounds checks and `array_index_nospec()` barriers in kernel code. There is no separate sysfs entry, no new CPU feature flag, and no distinct microcode change. This tool's existing CVE-2017-5753 checks already detect these mitigations (`__user pointer sanitization`, `usercopy/swapgs barriers`), so CVE-2018-3693 is fully covered as part of Spectre V1.
## CVE-2018-15572 — SpectreRSB (Return Stack Buffer)
- **Issue:** [#224](https://github.com/speed47/spectre-meltdown-checker/issues/224)
- **Research paper:** [Spectre Returns! Speculation Attacks using the Return Stack Buffer (WOOT'18)](https://arxiv.org/abs/1807.07940)
- **Kernel fix:** [commit fdf82a7856b3](https://github.com/torvalds/linux/commit/fdf82a7856b32d905c39afc85e34364491e46346) (Linux 4.18.1)
- **CVSS:** 6.5 (Medium)
The `spectre_v2_select_mitigation` function in the Linux kernel before 4.18.1 did not always fill the RSB upon a context switch, allowing userspace-to-userspace SpectreRSB attacks on Skylake+ CPUs where an empty RSB falls back to
he BTB.
**Why out of scope:** This CVE is a Spectre V2 mitigation gap (missing RSB filling on context switch), not a distinct hardware vulnerability. It is already fully covered by this tool's CVE-2017-5715 (Spectre V2) checks, which dete
ct whether the kernel performs RSB filling on CPUs vulnerable to RSB underflow (Skylake+ and RSBA-capable CPUs). A missing RSB fill is flagged as a caveat ("RSB filling missing on Skylake+") in the Spectre V2 verdict.
## CVE-2019-1125 — Spectre SWAPGS gadget
- **Issue:** [#301](https://github.com/speed47/spectre-meltdown-checker/issues/301)
- **Kernel fix:** [commit 18ec54fdd6d1](https://github.com/torvalds/linux/commit/18ec54fdd6d18d92025af097cd042a75cf0ea24c) (Linux 5.3)
- **CVSS:** 5.6 (Medium)
A Spectre V1 subvariant where the `SWAPGS` instruction can be speculatively executed on x86 CPUs, allowing an attacker to leak kernel memory via a side channel on the GS segment base value.
**Why out of scope:** This is a Spectre V1 subvariant whose mitigation (SWAPGS barriers) shares the same sysfs entry as CVE-2017-5753. This tool's existing CVE-2017-5753 checks already detect SWAPGS barriers: a mitigated kernel reports `"Mitigation: usercopy/swapgs barriers and __user pointer sanitization"`, while a kernel lacking the fix reports `"Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers"`. CVE-2019-1125 is therefore fully covered as part of Spectre V1.
## CVE-2019-15902 — Spectre V1 backport regression
- **Issue:** [#304](https://github.com/speed47/spectre-meltdown-checker/issues/304)
@@ -55,6 +97,26 @@ A backporting mistake in Linux stable/longterm kernel versions (4.4.x through 4.
**Why out of scope:** This is a kernel bug (bad backport), not a hardware vulnerability. The flawed code is not detectable on a running kernel without hardcoding kernel version ranges, which is against this tool's design principles. As the tool author noted: "it's going to be almost impossible to detect it on a running kernel."
## CVE-2020-12965 — Transient Execution of Non-Canonical Accesses (SLAM)
- **Issue:** [#478](https://github.com/speed47/spectre-meltdown-checker/issues/478)
- **Bulletin:** [AMD-SB-1010](https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1010)
- **Research paper:** [SLAM (VUSec)](https://www.vusec.net/projects/slam/)
- **CVSS:** 7.5 (High)
AMD CPUs may transiently execute non-canonical loads and stores using only the lower 48 address bits, potentially resulting in data leakage. The SLAM research (2023) demonstrated that this could be exploited on existing AMD Zen+/Zen2 CPUs and could also affect future CPUs with Intel LAM, AMD UAI, or ARM TBI features.
**Why out of scope:** AMD's mitigation guidance is for software vendors to "analyze their code for any potential vulnerabilities" and insert LFENCE or use existing speculation mitigation techniques in their own code. No microcode or kernel-level mitigations have been issued. The responsibility falls on individual software, not on the kernel or firmware, leaving nothing for this script to check.
## CVE-2024-7881 — ARM Prefetcher Privilege Escalation
- **Affected CPUs:** Specific ARM cores only
- **CVSS:** 5.1 (Medium)
The prefetch engine on certain ARM cores can fetch data from privileged memory locations. Mitigation is disabling the affected prefetcher via the `CPUACTLR6_EL1[41]` register bit.
**Why out of scope:** ARM-specific with very narrow scope and no Linux sysfs integration. The mitigation is a per-core register tweak, not a kernel or microcode update detectable by this tool.
## CVE-2024-36348 — AMD Transient Scheduler Attack (UMIP bypass)
- **Bulletin:** [AMD-SB-7029](https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7029.html)
@@ -72,3 +134,39 @@ A transient execution vulnerability in some AMD processors may allow a user proc
A transient execution vulnerability in some AMD processors may allow a user process to infer TSC_AUX even when such a read is disabled.
**Why out of scope:** AMD has determined that "leakage of TSC_AUX does not result in leakage of sensitive information" and has marked this CVE as "No fix planned" across all affected product lines. No microcode or kernel mitigations have been issued, leaving nothing for this script to check.
---
# Not a transient/speculative execution vulnerability
These are hardware flaws but not side-channel or speculative execution issues. They fall outside the vulnerability class this tool is designed to detect.
## CVE-2023-31315 — SinkClose (AMD SMM Lock Bypass)
- **Issue:** [#499](https://github.com/speed47/spectre-meltdown-checker/issues/499)
- **Bulletin:** [AMD-SB-7014](https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7014.html)
- **Research:** [AMD SinkClose (IOActive, DEF CON 32)](https://www.ioactive.com/resources/amd-sinkclose-universal-ring-2-privilege-escalation)
- **Affected CPUs:** AMD Zen 15 (EPYC, Ryzen, Threadripper, Embedded)
- **CVSS:** 7.5 (High)
Improper validation in a model-specific register (MSR) allows a program with ring 0 (kernel) access to modify System Management Mode (SMM) configuration while SMI lock is enabled, escalating privileges from ring 0 to ring -2 (SMM). AMD provides two mitigation paths: BIOS/AGESA firmware updates (all product lines) and hot-loadable microcode updates (EPYC server processors only).
**Why out of scope:** Not a transient or speculative execution vulnerability — this is a privilege escalation via MSR manipulation, with no side-channel component. It requires ring 0 access as a prerequisite, fundamentally different from Spectre/Meltdown-class attacks where unprivileged code can leak data across privilege boundaries. There is no Linux kernel sysfs entry and no kernel-side mitigation. Although AMD provides hot-loadable microcode for some EPYC processors, the client and embedded product lines are mitigated only through BIOS firmware updates, which this tool cannot detect.
## CVE-2024-56161 — EntrySign (AMD Microcode Signature Bypass)
- **Affected CPUs:** AMD Zen 1-5
- **CVSS:** 7.2 (High)
A weakness in AMD's microcode signature verification (AES-CMAC hash) allows loading arbitrary unsigned microcode with administrator privileges.
**Why out of scope:** This is a microcode integrity/authentication issue, not a speculative execution vulnerability. It does not involve transient execution side channels and is outside the scope of this tool.
## CVE-2025-29943 — StackWarp (AMD SEV-SNP)
- **Affected CPUs:** AMD Zen 1-5
- **CVSS:** Low
Exploits a synchronization failure in the AMD stack engine via an undocumented MSR bit, targeting AMD SEV-SNP confidential VMs. Requires hypervisor-level (ring 0) access.
**Why out of scope:** Not a transient/speculative execution side channel. This is an architectural attack on AMD SEV-SNP confidential computing that requires hypervisor access, which is outside the threat model of this tool.

40
dist/README.md vendored
View File

@@ -16,11 +16,11 @@ CVE | Name | Aliases
[CVE-2018-3620](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3620) | L1 Terminal Fault | Foreshadow-NG (OS/SMM)
[CVE-2018-3646](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3646) | L1 Terminal Fault | Foreshadow-NG (VMM)
[CVE-2018-12126](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12126) | Microarchitectural Store Buffer Data Sampling | MSBDS, Fallout
[CVE-2018-12130](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12130) | Microarchitectural Fill Buffer Data Sampling | MFBDS, ZombieLoad
[CVE-2018-12127](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12127) | Microarchitectural Load Port Data Sampling | MLPDS, RIDL
[CVE-2018-12130](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12130) | Microarchitectural Fill Buffer Data Sampling | MFBDS, ZombieLoad
[CVE-2018-12207](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12207) | Machine Check Exception on Page Size Changes | iTLB Multihit, No eXcuses
[CVE-2019-11091](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11091) | Microarchitectural Data Sampling Uncacheable Memory | MDSUM, RIDL
[CVE-2019-11135](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11135) | TSX Asynchronous Abort | TAA, ZombieLoad V2
[CVE-2018-12207](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12207) | Machine Check Exception on Page Size Changes | iTLB Multihit, No eXcuses
[CVE-2020-0543](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0543) | Special Register Buffer Data Sampling | SRBDS, CROSSTalk
[CVE-2022-29900](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29900) | Arbitrary Speculative Code Execution with Return Instructions | Retbleed (AMD)
[CVE-2022-29901](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29901) | Arbitrary Speculative Code Execution with Return Instructions | Retbleed (Intel), RSBA
@@ -28,8 +28,11 @@ CVE | Name | Aliases
[CVE-2023-20569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20569) | Return Address Security | Inception, SRSO
[CVE-2023-20593](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20593) | Cross-Process Information Leak | Zenbleed
[CVE-2023-23583](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23583) | Redundant Prefix Issue | Reptar
[CVE-2024-28956](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-28956) | Indirect Target Selection | ITS
[CVE-2024-36350](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-36350) | Transient Scheduler Attack, Store Queue | TSA-SQ
[CVE-2024-36357](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-36357) | Transient Scheduler Attack, L1 | TSA-L1
[CVE-2025-40300](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-40300) | VM-Exit Stale Branch Prediction | VMScape
[CVE-2024-45332](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-45332) | Branch Privilege Injection | BPI
## Am I at risk?
@@ -47,11 +50,11 @@ CVE-2018-3615 (Foreshadow, SGX) | ✅ (3) | ✅ (3) | ✅ (3) | ✅ (3) | Microc
CVE-2018-3620 (Foreshadow-NG, OS/SMM) | 💥 | ✅ | ✅ | ✅ | Kernel update
CVE-2018-3646 (Foreshadow-NG, VMM) | ✅ | ✅ | 💥 | 💥 | Kernel update (or disable EPT/SMT)
CVE-2018-12126 (MSBDS, Fallout) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
CVE-2018-12130 (MFBDS, ZombieLoad) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
CVE-2018-12127 (MLPDS, RIDL) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
CVE-2018-12130 (MFBDS, ZombieLoad) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
CVE-2018-12207 (iTLB Multihit, No eXcuses) | ✅ | ✅ | ☠️ | ✅ | Hypervisor update (or disable hugepages)
CVE-2019-11091 (MDSUM, RIDL) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
CVE-2019-11135 (TAA, ZombieLoad V2) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
CVE-2018-12207 (iTLB Multihit, No eXcuses) | ✅ | ✅ | ☠️ | ✅ | Hypervisor update (or disable hugepages)
CVE-2020-0543 (SRBDS, CROSSTalk) | 💥 (2) | 💥 (2) | 💥 (2) | 💥 (2) | Microcode + kernel update
CVE-2022-29900 (Retbleed AMD) | 💥 | ✅ | 💥 | ✅ | Kernel update (+ microcode for IBPB)
CVE-2022-29901 (Retbleed Intel, RSBA) | 💥 | ✅ | 💥 | ✅ | Microcode + kernel update (eIBRS or IBRS)
@@ -59,8 +62,11 @@ CVE-2022-40982 (Downfall, GDS) | 💥 | 💥 | 💥 | 💥 | Microcode update (o
CVE-2023-20569 (Inception, SRSO) | 💥 | ✅ | 💥 | ✅ | Microcode + kernel update
CVE-2023-20593 (Zenbleed) | 💥 | 💥 | 💥 | 💥 | Microcode update (or kernel workaround)
CVE-2023-23583 (Reptar) | ☠️ | ☠️ | ☠️ | ☠️ | Microcode update
CVE-2024-28956 (ITS) | 💥 | ✅ | 💥 (4) | ✅ | Microcode + kernel update
CVE-2024-36350 (TSA-SQ) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
CVE-2024-36357 (TSA-L1) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
CVE-2025-40300 (VMScape) | ✅ | ✅ | 💥 | ✅ | Kernel update (IBPB on VM-exit)
CVE-2024-45332 (BPI) | 💥 | ✅ | 💥 | ✅ | Microcode update
> 💥 Data can be leaked across this boundary.
@@ -74,6 +80,8 @@ CVE-2024-36357 (TSA-L1) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel
> (3) CVE-2018-3615 (Foreshadow SGX) inverts the normal trust model: the OS reads SGX enclave data. It is irrelevant unless the system runs SGX enclaves, and the attacker must already have OS-level access.
> (4) VM→Host leakage applies only to certain affected CPU models (Skylake-X, Kaby Lake, Comet Lake). Ice Lake, Tiger Lake, and Rocket Lake are only affected for native (user-to-kernel) attacks, not guest-to-host.
## Detailed CVE descriptions
<details>
@@ -113,22 +121,22 @@ A guest VM can exploit L1TF to read memory belonging to the host or other guests
**CVE-2018-12126 — Microarchitectural Store Buffer Data Sampling (MSBDS, Fallout)**
**CVE-2018-12130 — Microarchitectural Fill Buffer Data Sampling (MFBDS, ZombieLoad)**
**CVE-2018-12127 — Microarchitectural Load Port Data Sampling (MLPDS, RIDL)**
**CVE-2018-12130 — Microarchitectural Fill Buffer Data Sampling (MFBDS, ZombieLoad)**
**CVE-2019-11091 — Microarchitectural Data Sampling Uncacheable Memory (MDSUM, RIDL)**
These four CVEs are collectively known as "MDS" (Microarchitectural Data Sampling) vulnerabilities. They exploit different CPU internal buffers — store buffer, fill buffer, load ports, and uncacheable memory paths — that can leak recently accessed data across privilege boundaries during speculative execution. An unprivileged attacker can observe data recently processed by the kernel or other processes. Mitigation requires a microcode update (providing the MD_CLEAR mechanism) plus a kernel update that uses VERW to clear affected buffers on privilege transitions. Disabling Hyper-Threading (SMT) provides additional protection because sibling threads share these buffers. The performance impact is low to significant, depending on the frequency of kernel transitions and whether SMT is disabled.
**CVE-2019-11135 — TSX Asynchronous Abort (TAA, ZombieLoad V2)**
On CPUs with Intel TSX, a transactional abort can leave data from the line fill buffers in a state observable through side channels, similar to the MDS vulnerabilities but triggered through TSX. Mitigation requires a microcode update plus kernel support to either clear affected buffers or disable TSX entirely (via the TSX_CTRL MSR). The performance impact is low to significant, similar to MDS, with the option to eliminate the attack surface entirely by disabling TSX at the cost of losing transactional memory support.
**CVE-2018-12207 — Machine Check Exception on Page Size Changes (iTLB Multihit, No eXcuses)**
A malicious guest VM can trigger a machine check exception (MCE) — crashing the entire host — by creating specific conditions in the instruction TLB involving page size changes. This is a denial-of-service vulnerability affecting hypervisors running untrusted guests. Mitigation requires either disabling hugepage use in the hypervisor or updating the hypervisor to avoid the problematic iTLB configurations. The performance impact ranges from low to significant depending on the approach: disabling hugepages can substantially impact memory-intensive workloads.
**CVE-2019-11135 — TSX Asynchronous Abort (TAA, ZombieLoad V2)**
On CPUs with Intel TSX, a transactional abort can leave data from the line fill buffers in a state observable through side channels, similar to the MDS vulnerabilities but triggered through TSX. Mitigation requires a microcode update plus kernel support to either clear affected buffers or disable TSX entirely (via the TSX_CTRL MSR). The performance impact is low to significant, similar to MDS, with the option to eliminate the attack surface entirely by disabling TSX at the cost of losing transactional memory support.
**CVE-2020-0543 — Special Register Buffer Data Sampling (SRBDS, CROSSTalk)**
Certain special CPU instructions (RDRAND, RDSEED, EGETKEY) read data through a shared staging buffer that is accessible across all cores via speculative execution. An attacker running code on any core can observe the output of these instructions from a victim on a different core, including extracting cryptographic keys from SGX enclaves (a complete ECDSA key was demonstrated). This is notable as one of the first cross-core speculative execution attacks. Mitigation requires a microcode update that serializes access to the staging buffer, plus a kernel update to manage the mitigation. Performance impact is low, mainly affecting workloads that heavily use RDRAND/RDSEED.
@@ -157,6 +165,10 @@ A bug in AMD Zen 2 processors causes the VZEROUPPER instruction to incorrectly z
A bug in Intel processors causes unexpected behavior when executing instructions with specific redundant REX prefixes. Depending on the circumstances, this can result in a system crash (MCE), unpredictable behavior, or potentially privilege escalation. Any software running on an affected CPU can trigger the bug. Mitigation requires a microcode update. Performance impact is low.
**CVE-2024-28956 — Indirect Target Selection (ITS)**
On certain Intel processors (Skylake-X stepping 6+, Kaby Lake, Comet Lake, Ice Lake, Tiger Lake, Rocket Lake), an attacker can train the indirect branch predictor to speculatively execute a targeted gadget in the kernel, bypassing eIBRS protections. The Branch Target Buffer (BTB) uses only partial address bits to index indirect branch targets, allowing user-space code to influence kernel-space speculative execution. Some affected CPUs (Ice Lake, Tiger Lake, Rocket Lake) are only vulnerable to native user-to-kernel attacks, not guest-to-host (VMX) attacks. Mitigation requires both a microcode update (IPU 2025.1 / microcode-20250512+, which fixes IBPB to fully flush indirect branch predictions) and a kernel update (CONFIG_MITIGATION_ITS, Linux 6.15+) that aligns branch/return thunks or uses RSB stuffing. Performance impact is low.
**CVE-2024-36350 — Transient Scheduler Attack, Store Queue (TSA-SQ)**
On AMD Zen 3 and Zen 4 processors, the CPU's transient scheduler may speculatively retrieve stale data from the store queue during certain timing windows, allowing an attacker to infer data from previous store operations across privilege boundaries. The attack can also leak data between SMT sibling threads. Mitigation requires both a microcode update (exposing the VERW_CLEAR capability) and a kernel update (CONFIG_MITIGATION_TSA, Linux 6.16+) that uses the VERW instruction to clear CPU buffers on user/kernel transitions and before VMRUN. The kernel also clears buffers on idle when SMT is active. Performance impact is low to medium.
@@ -165,6 +177,14 @@ On AMD Zen 3 and Zen 4 processors, the CPU's transient scheduler may speculative
On AMD Zen 3 and Zen 4 processors, the CPU's transient scheduler may speculatively retrieve stale data from the L1 data cache during certain timing windows, allowing an attacker to infer data in the L1D cache across privilege boundaries. Mitigation requires the same microcode and kernel updates as TSA-SQ: a microcode update exposing VERW_CLEAR and a kernel update (CONFIG_MITIGATION_TSA, Linux 6.16+) that clears CPU buffers via VERW on privilege transitions. Performance impact is low to medium.
**CVE-2025-40300 — VM-Exit Stale Branch Prediction (VMScape)**
After a guest VM exits to the host, stale branch predictions from the guest can influence host-side speculative execution before the kernel returns to userspace, allowing a local attacker to leak host kernel memory. This affects Intel processors from Sandy Bridge through Arrow Lake/Lunar Lake, AMD Zen 1 through Zen 5 families, and Hygon family 0x18. Only systems running a hypervisor with untrusted guests are at risk. Mitigation requires a kernel update (CONFIG_MITIGATION_VMSCAPE, Linux 6.18+) that issues IBPB before returning to userspace after a VM exit. No specific microcode update is required beyond existing IBPB support. Performance impact is low.
**CVE-2024-45332 — Branch Privilege Injection (BPI)**
A race condition in the branch predictor update mechanism of Intel processors (Coffee Lake through Raptor Lake, plus some server and Atom parts) allows user-space branch predictions to briefly influence kernel-space speculative execution, undermining eIBRS and IBPB protections. This means systems relying solely on eIBRS for Spectre V2 mitigation may not be fully protected without the microcode fix. Mitigation requires a microcode update (intel-microcode 20250512+) that fixes the asynchronous branch predictor update timing so that eIBRS and IBPB work as originally intended. No kernel changes are required. Performance impact is negligible.
</details>
## Unsupported CVEs

View File

@@ -161,6 +161,9 @@ CVE-2023-20569|INCEPTION|inception|Inception, return address security (RAS)
CVE-2023-23583|REPTAR|reptar|Reptar, redundant prefix issue
CVE-2024-36350|TSA_SQ|tsa|Transient Scheduler Attack - Store Queue (TSA-SQ)
CVE-2024-36357|TSA_L1|tsa|Transient Scheduler Attack - L1 (TSA-L1)
CVE-2024-28956|ITS|its|Indirect Target Selection (ITS)
CVE-2025-40300|VMSCAPE|vmscape|VMScape, VM-exit stale branch prediction
CVE-2024-45332|BPI|bpi|Branch Privilege Injection (BPI)
'
# Derive the supported CVE list from the registry

View File

@@ -0,0 +1,105 @@
# vim: set ts=4 sw=4 sts=4 et:
# AUTO-GENERATED FILE — DO NOT EDIT MANUALLY.
# Generated by scripts/update_intel_models.sh from:
# https://raw.githubusercontent.com/torvalds/linux/refs/heads/master/arch/x86/include/asm/intel-family.h
# Run scripts/update_intel_models.sh to refresh when new Intel CPU families are added to the kernel.
# shellcheck disable=SC2034
{
readonly INTEL_FAM5_PENTIUM_75=$((0x02)) # /* P54C */
readonly INTEL_FAM5_PENTIUM_MMX=$((0x04)) # /* P55C */
readonly INTEL_FAM5_QUARK_X1000=$((0x09)) # /* Quark X1000 SoC */
readonly INTEL_FAM6_PENTIUM_PRO=$((0x01))
readonly INTEL_FAM6_PENTIUM_II_KLAMATH=$((0x03))
readonly INTEL_FAM6_PENTIUM_III_DESCHUTES=$((0x05))
readonly INTEL_FAM6_PENTIUM_III_TUALATIN=$((0x0B))
readonly INTEL_FAM6_PENTIUM_M_DOTHAN=$((0x0D))
readonly INTEL_FAM6_CORE_YONAH=$((0x0E))
readonly INTEL_FAM6_CORE2_MEROM=$((0x0F))
readonly INTEL_FAM6_CORE2_MEROM_L=$((0x16))
readonly INTEL_FAM6_CORE2_PENRYN=$((0x17))
readonly INTEL_FAM6_CORE2_DUNNINGTON=$((0x1D))
readonly INTEL_FAM6_NEHALEM=$((0x1E))
readonly INTEL_FAM6_NEHALEM_G=$((0x1F)) # /* Auburndale / Havendale */
readonly INTEL_FAM6_NEHALEM_EP=$((0x1A))
readonly INTEL_FAM6_NEHALEM_EX=$((0x2E))
readonly INTEL_FAM6_WESTMERE=$((0x25))
readonly INTEL_FAM6_WESTMERE_EP=$((0x2C))
readonly INTEL_FAM6_WESTMERE_EX=$((0x2F))
readonly INTEL_FAM6_SANDYBRIDGE=$((0x2A))
readonly INTEL_FAM6_SANDYBRIDGE_X=$((0x2D))
readonly INTEL_FAM6_IVYBRIDGE=$((0x3A))
readonly INTEL_FAM6_IVYBRIDGE_X=$((0x3E))
readonly INTEL_FAM6_HASWELL=$((0x3C))
readonly INTEL_FAM6_HASWELL_X=$((0x3F))
readonly INTEL_FAM6_HASWELL_L=$((0x45))
readonly INTEL_FAM6_HASWELL_G=$((0x46))
readonly INTEL_FAM6_BROADWELL=$((0x3D))
readonly INTEL_FAM6_BROADWELL_G=$((0x47))
readonly INTEL_FAM6_BROADWELL_X=$((0x4F))
readonly INTEL_FAM6_BROADWELL_D=$((0x56))
readonly INTEL_FAM6_SKYLAKE_L=$((0x4E)) # /* Sky Lake */
readonly INTEL_FAM6_SKYLAKE=$((0x5E)) # /* Sky Lake */
readonly INTEL_FAM6_SKYLAKE_X=$((0x55)) # /* Sky Lake */
readonly INTEL_FAM6_KABYLAKE_L=$((0x8E)) # /* Sky Lake */
readonly INTEL_FAM6_KABYLAKE=$((0x9E)) # /* Sky Lake */
readonly INTEL_FAM6_COMETLAKE=$((0xA5)) # /* Sky Lake */
readonly INTEL_FAM6_COMETLAKE_L=$((0xA6)) # /* Sky Lake */
readonly INTEL_FAM6_CANNONLAKE_L=$((0x66)) # /* Palm Cove */
readonly INTEL_FAM6_ICELAKE_X=$((0x6A)) # /* Sunny Cove */
readonly INTEL_FAM6_ICELAKE_D=$((0x6C)) # /* Sunny Cove */
readonly INTEL_FAM6_ICELAKE=$((0x7D)) # /* Sunny Cove */
readonly INTEL_FAM6_ICELAKE_L=$((0x7E)) # /* Sunny Cove */
readonly INTEL_FAM6_ICELAKE_NNPI=$((0x9D)) # /* Sunny Cove */
readonly INTEL_FAM6_ROCKETLAKE=$((0xA7)) # /* Cypress Cove */
readonly INTEL_FAM6_TIGERLAKE_L=$((0x8C)) # /* Willow Cove */
readonly INTEL_FAM6_TIGERLAKE=$((0x8D)) # /* Willow Cove */
readonly INTEL_FAM6_SAPPHIRERAPIDS_X=$((0x8F)) # /* Golden Cove */
readonly INTEL_FAM6_EMERALDRAPIDS_X=$((0xCF)) # /* Raptor Cove */
readonly INTEL_FAM6_GRANITERAPIDS_X=$((0xAD)) # /* Redwood Cove */
readonly INTEL_FAM6_GRANITERAPIDS_D=$((0xAE))
readonly INTEL_FAM19_DIAMONDRAPIDS_X=$((0x01)) # /* Panther Cove */
readonly INTEL_FAM6_BARTLETTLAKE=$((0xD7)) # /* Raptor Cove */
readonly INTEL_FAM6_LAKEFIELD=$((0x8A)) # /* Sunny Cove / Tremont */
readonly INTEL_FAM6_ALDERLAKE=$((0x97)) # /* Golden Cove / Gracemont */
readonly INTEL_FAM6_ALDERLAKE_L=$((0x9A)) # /* Golden Cove / Gracemont */
readonly INTEL_FAM6_RAPTORLAKE=$((0xB7)) # /* Raptor Cove / Enhanced Gracemont */
readonly INTEL_FAM6_RAPTORLAKE_P=$((0xBA))
readonly INTEL_FAM6_RAPTORLAKE_S=$((0xBF))
readonly INTEL_FAM6_METEORLAKE=$((0xAC)) # /* Redwood Cove / Crestmont */
readonly INTEL_FAM6_METEORLAKE_L=$((0xAA))
readonly INTEL_FAM6_ARROWLAKE_H=$((0xC5)) # /* Lion Cove / Skymont */
readonly INTEL_FAM6_ARROWLAKE=$((0xC6))
readonly INTEL_FAM6_ARROWLAKE_U=$((0xB5))
readonly INTEL_FAM6_LUNARLAKE_M=$((0xBD)) # /* Lion Cove / Skymont */
readonly INTEL_FAM6_PANTHERLAKE_L=$((0xCC)) # /* Cougar Cove / Darkmont */
readonly INTEL_FAM6_WILDCATLAKE_L=$((0xD5))
readonly INTEL_FAM18_NOVALAKE=$((0x01)) # /* Coyote Cove / Arctic Wolf */
readonly INTEL_FAM18_NOVALAKE_L=$((0x03)) # /* Coyote Cove / Arctic Wolf */
readonly INTEL_FAM6_ATOM_BONNELL=$((0x1C)) # /* Diamondville, Pineview */
readonly INTEL_FAM6_ATOM_BONNELL_MID=$((0x26)) # /* Silverthorne, Lincroft */
readonly INTEL_FAM6_ATOM_SALTWELL=$((0x36)) # /* Cedarview */
readonly INTEL_FAM6_ATOM_SALTWELL_MID=$((0x27)) # /* Penwell */
readonly INTEL_FAM6_ATOM_SALTWELL_TABLET=$((0x35)) # /* Cloverview */
readonly INTEL_FAM6_ATOM_SILVERMONT=$((0x37)) # /* Bay Trail, Valleyview */
readonly INTEL_FAM6_ATOM_SILVERMONT_D=$((0x4D)) # /* Avaton, Rangely */
readonly INTEL_FAM6_ATOM_SILVERMONT_MID=$((0x4A)) # /* Merriefield */
readonly INTEL_FAM6_ATOM_SILVERMONT_MID2=$((0x5A)) # /* Anniedale */
readonly INTEL_FAM6_ATOM_AIRMONT=$((0x4C)) # /* Cherry Trail, Braswell */
readonly INTEL_FAM6_ATOM_AIRMONT_NP=$((0x75)) # /* Lightning Mountain */
readonly INTEL_FAM6_ATOM_GOLDMONT=$((0x5C)) # /* Apollo Lake */
readonly INTEL_FAM6_ATOM_GOLDMONT_D=$((0x5F)) # /* Denverton */
readonly INTEL_FAM6_ATOM_GOLDMONT_PLUS=$((0x7A)) # /* Gemini Lake */
readonly INTEL_FAM6_ATOM_TREMONT_D=$((0x86)) # /* Jacobsville */
readonly INTEL_FAM6_ATOM_TREMONT=$((0x96)) # /* Elkhart Lake */
readonly INTEL_FAM6_ATOM_TREMONT_L=$((0x9C)) # /* Jasper Lake */
readonly INTEL_FAM6_ATOM_GRACEMONT=$((0xBE)) # /* Alderlake N */
readonly INTEL_FAM6_ATOM_CRESTMONT_X=$((0xAF)) # /* Sierra Forest */
readonly INTEL_FAM6_ATOM_CRESTMONT=$((0xB6)) # /* Grand Ridge */
readonly INTEL_FAM6_ATOM_DARKMONT_X=$((0xDD)) # /* Clearwater Forest */
readonly INTEL_FAM6_XEON_PHI_KNL=$((0x57)) # /* Knights Landing */
readonly INTEL_FAM6_XEON_PHI_KNM=$((0x85)) # /* Knights Mill */
readonly INTEL_FAM15_P4_WILLAMETTE=$((0x01)) # /* Also Xeon Foster */
readonly INTEL_FAM15_P4_PRESCOTT=$((0x03))
readonly INTEL_FAM15_P4_PRESCOTT_2M=$((0x04))
readonly INTEL_FAM15_P4_CEDARMILL=$((0x06)) # /* Also Xeon Dempsey */
}

View File

@@ -42,7 +42,7 @@ _is_cpu_affected_cached() {
# Args: $1=cve_id (one of the $g_supported_cve_list items)
# Returns: 0 if affected, 1 if not affected
is_cpu_affected() {
local result cpuid_hex reptar_ucode_list tuple fixed_ucode_ver affected_fmspi affected_fms ucode_platformid_mask affected_cpuid i cpupart cpuarch
local result cpuid_hex reptar_ucode_list bpi_ucode_list tuple fixed_ucode_ver affected_fmspi affected_fms ucode_platformid_mask affected_cpuid i cpupart cpuarch
# if CPU is Intel and is in our dump of the Intel official affected CPUs page, use it:
if is_intel; then
@@ -106,9 +106,13 @@ is_cpu_affected() {
_set_immune tsa
# Retbleed: AMD (CVE-2022-29900) and Intel (CVE-2022-29901) specific:
_set_immune retbleed
# Downfall & Reptar are Intel specific, look for "is_intel" below:
# Downfall, Reptar, ITS & BPI are Intel specific, look for "is_intel" below:
_set_immune downfall
_set_immune reptar
_set_immune its
_set_immune bpi
# VMScape affects Intel, AMD and Hygon — set immune, overridden below:
_set_immune vmscape
if is_cpu_mds_free; then
_infer_immune msbds
@@ -261,21 +265,48 @@ is_cpu_affected() {
fi
set +u
fi
# ITS (Indirect Target Selection, CVE-2024-28956)
# kernel vulnerable_to_its() + cpu_vuln_blacklist (159013a7ca18)
# immunity: ARCH_CAP_ITS_NO (bit 62 of IA32_ARCH_CAPABILITIES)
# immunity: X86_FEATURE_BHI_CTRL (none of the affected CPUs have this)
# vendor scope: Intel only (family 6), with stepping constraints on some models
if [ "$cap_its_no" = 1 ]; then
pr_debug "is_cpu_affected: its: not affected (ITS_NO)"
_set_immune its
elif [ "$cpu_family" = 6 ]; then
set -u
if { [ "$cpu_model" = "$INTEL_FAM6_SKYLAKE_X" ] && [ "$cpu_stepping" -gt 5 ]; } ||
{ [ "$cpu_model" = "$INTEL_FAM6_KABYLAKE_L" ] && [ "$cpu_stepping" -gt 11 ]; } ||
{ [ "$cpu_model" = "$INTEL_FAM6_KABYLAKE" ] && [ "$cpu_stepping" -gt 12 ]; } ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_D" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_COMETLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_COMETLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_TIGERLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_TIGERLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ROCKETLAKE" ]; then
pr_debug "is_cpu_affected: its: affected"
_set_vuln its
fi
set +u
fi
# Reptar
# the only way to know whether a CPU is vuln, is to check whether there is a known ucode update for it,
# as the mitigation is only ucode-based and there's no flag exposed by the kernel or by an updated ucode.
# we have to hardcode the truthtable of affected CPUs vs updated ucodes...
# https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/redundant-prefix-issue.html
# list taken from:
# list initially taken from:
# https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/commit/ece0d294a29a1375397941a4e6f2f7217910bc89#diff-e6fad0f2abbac6c9603b2e8f88fe1d151a83de708aeca1c1d93d881c958ecba4R26
# both pages have a lot of inconsistencies, I've tried to fix the errors the best I could, the logic being: if it's not in the
# blog page, then the microcode update in the commit is not related to reptar, if microcode versions differ, then the one in github is correct,
# if a stepping exists in the blog page but not in the commit, then the blog page is right
# updated 2026-04 with Intel affected processor list + releasenote.md:
# added 06-9a-04/40 (AZB), 06-bd-01/80 (Lunar Lake, post-dates Reptar: first ucode already includes fix)
g_reptar_fixed_ucode_version=''
reptar_ucode_list='
06-97-02/07,00000032
06-97-05/07,00000032
06-9a-03/80,00000430
06-9a-04/80,00000430
06-9a-04/40,00000005
06-6c-01/10,01000268
06-6a-06/87,0d0003b9
06-7e-05/80,000000c2
@@ -296,6 +327,7 @@ is_cpu_affected() {
06-8d-01/c2,0000004e
06-8d-00/c2,0000004e
06-8c-02/c2,00000034
06-bd-01/80,0000011f
'
for tuple in $reptar_ucode_list; do
fixed_ucode_ver=$((0x$(echo "$tuple" | cut -d, -f2)))
@@ -309,12 +341,35 @@ is_cpu_affected() {
0x"$(echo "$affected_fms" | cut -d- -f3)"
)
if [ "$cpu_cpuid" = "$affected_cpuid" ] && [ $((cpu_platformid & ucode_platformid_mask)) -gt 0 ]; then
# this is not perfect as Intel never tells about their EOL CPUs, so more CPUs might be affected but there's no way to tell
_set_vuln reptar
g_reptar_fixed_ucode_version=$fixed_ucode_ver
break
fi
done
# if we didn't match the ucode list above, also check the model blacklist:
# Intel never tells about their EOL CPUs, so more CPUs might be affected
# than the ones that received a microcode update (e.g. steppings with
# different platform IDs that were dropped before the Reptar fix).
if [ -z "$g_reptar_fixed_ucode_version" ] && [ "$cpu_family" = 6 ]; then
set -u
if [ "$cpu_model" = "$INTEL_FAM6_ALDERLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ALDERLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_D" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ROCKETLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_TIGERLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_TIGERLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_SAPPHIRERAPIDS_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE_P" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE_S" ] ||
[ "$cpu_model" = "$INTEL_FAM6_LUNARLAKE_M" ]; then
pr_debug "is_cpu_affected: reptar: affected (model match, no known fixing ucode)"
_set_vuln reptar
fi
set +u
fi
# Retbleed (Intel, CVE-2022-29901): Skylake through Rocket Lake, or any CPU with RSBA
# kernel cpu_vuln_blacklist for RETBLEED (6b80b59b3555, 6ad0ad2bf8a6, f54d45372c6a)
@@ -337,6 +392,158 @@ is_cpu_affected() {
fi
fi
# VMScape (CVE-2025-40300): Intel model blacklist
# kernel cpu_vuln_blacklist VMSCAPE (a508cec6e521 + 8a68d64bb103)
# immunity: no ARCH_CAP bits (purely blacklist-based)
# note: kernel only sets bug on bare metal (!X86_FEATURE_HYPERVISOR)
# vendor scope: Intel + AMD + Hygon (AMD/Hygon handled below)
if [ "$cpu_family" = 6 ]; then
set -u
if [ "$cpu_model" = "$INTEL_FAM6_SANDYBRIDGE_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_SANDYBRIDGE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_IVYBRIDGE_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_IVYBRIDGE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_HASWELL" ] ||
[ "$cpu_model" = "$INTEL_FAM6_HASWELL_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_HASWELL_G" ] ||
[ "$cpu_model" = "$INTEL_FAM6_HASWELL_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_BROADWELL_D" ] ||
[ "$cpu_model" = "$INTEL_FAM6_BROADWELL_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_BROADWELL_G" ] ||
[ "$cpu_model" = "$INTEL_FAM6_BROADWELL" ] ||
[ "$cpu_model" = "$INTEL_FAM6_SKYLAKE_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_SKYLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_SKYLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_KABYLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_KABYLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_CANNONLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_COMETLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_COMETLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ALDERLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ALDERLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE_P" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE_S" ] ||
[ "$cpu_model" = "$INTEL_FAM6_METEORLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ARROWLAKE_H" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ARROWLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ARROWLAKE_U" ] ||
[ "$cpu_model" = "$INTEL_FAM6_LUNARLAKE_M" ] ||
[ "$cpu_model" = "$INTEL_FAM6_SAPPHIRERAPIDS_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_GRANITERAPIDS_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_EMERALDRAPIDS_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ATOM_GRACEMONT" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ATOM_CRESTMONT_X" ]; then
pr_debug "is_cpu_affected: vmscape: affected"
_set_vuln vmscape
fi
set +u
fi
# BPI (Branch Privilege Injection, CVE-2024-45332)
# microcode-only fix, no kernel X86_BUG flag, no CPUID/MSR indicator for the fix.
# We have to hardcode the truthtable of affected CPUs vs fixing ucodes,
# same approach as Reptar (see above).
# https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/indirect-branch-predictor-delayed-updates.html
# list taken from Intel affected processor list + Intel-Linux-Processor-Microcode-Data-Files releasenote.md
# format: FF-MM-SS/platformid_mask,fixed_ucode_version
g_bpi_fixed_ucode_version=''
bpi_ucode_list='
06-9e-0d/22,00000104
06-8e-0a/c0,000000f6
06-8e-0b/d0,000000f6
06-8e-0c/94,00000100
06-a5-02/20,00000100
06-a5-03/22,00000100
06-a5-05/22,00000100
06-a6-00/80,00000102
06-a6-01/80,00000100
06-a7-01/02,00000065
06-7e-05/80,000000cc
06-6a-06/87,0d000421
06-6c-01/10,010002f1
06-8c-01/80,000000be
06-8c-02/c2,0000003e
06-8d-01/c2,00000058
06-97-02/07,0000003e
06-97-05/07,0000003e
06-9a-03/80,0000043b
06-9a-04/80,0000043b
06-9a-04/40,0000000c
06-be-00/19,00000021
06-b7-01/32,00000133
06-ba-02/e0,00006134
06-ba-03/e0,00006134
06-bf-02/07,0000003e
06-bf-05/07,0000003e
06-aa-04/e6,00000028
06-b5-00/80,0000000d
06-c5-02/82,0000011b
06-c6-02/82,0000011b
06-bd-01/80,00000125
06-55-0b/bf,07002b01
06-8f-07/87,2b000661
06-8f-08/87,2b000661
06-8f-08/10,2c000421
06-cf-02/87,210002d3
06-7a-08/01,00000026
'
for tuple in $bpi_ucode_list; do
fixed_ucode_ver=$((0x$(echo "$tuple" | cut -d, -f2)))
affected_fmspi=$(echo "$tuple" | cut -d, -f1)
affected_fms=$(echo "$affected_fmspi" | cut -d/ -f1)
ucode_platformid_mask=0x$(echo "$affected_fmspi" | cut -d/ -f2)
affected_cpuid=$(
fms2cpuid \
0x"$(echo "$affected_fms" | cut -d- -f1)" \
0x"$(echo "$affected_fms" | cut -d- -f2)" \
0x"$(echo "$affected_fms" | cut -d- -f3)"
)
if [ "$cpu_cpuid" = "$affected_cpuid" ] && [ $((cpu_platformid & ucode_platformid_mask)) -gt 0 ]; then
_set_vuln bpi
g_bpi_fixed_ucode_version=$fixed_ucode_ver
break
fi
done
# if we didn't match the ucode list above, also check the model blacklist:
# Intel never tells about their EOL CPUs, so more CPUs might be affected
# than the ones that received a microcode update. In that case, we flag
# the CPU as affected but g_bpi_fixed_ucode_version stays empty (the CVE
# check will handle this by reporting VULN with no known fix).
if [ -z "$g_bpi_fixed_ucode_version" ] && [ "$cpu_family" = 6 ]; then
set -u
if [ "$cpu_model" = "$INTEL_FAM6_KABYLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_KABYLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_COMETLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_COMETLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ROCKETLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ICELAKE_D" ] ||
[ "$cpu_model" = "$INTEL_FAM6_TIGERLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_TIGERLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ALDERLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ALDERLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ATOM_GRACEMONT" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE_P" ] ||
[ "$cpu_model" = "$INTEL_FAM6_RAPTORLAKE_S" ] ||
[ "$cpu_model" = "$INTEL_FAM6_METEORLAKE_L" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ARROWLAKE_H" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ARROWLAKE" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ARROWLAKE_U" ] ||
[ "$cpu_model" = "$INTEL_FAM6_LUNARLAKE_M" ] ||
[ "$cpu_model" = "$INTEL_FAM6_SKYLAKE_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_SAPPHIRERAPIDS_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_EMERALDRAPIDS_X" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ATOM_GOLDMONT_PLUS" ] ||
[ "$cpu_model" = "$INTEL_FAM6_ATOM_CRESTMONT" ]; then
pr_debug "is_cpu_affected: bpi: affected (model match, no known fixing ucode)"
_set_vuln bpi
fi
set +u
fi
elif is_amd || is_hygon; then
# AMD revised their statement about affected_variant2 => affected
# https://www.amd.com/en/corporate/speculative-execution
@@ -378,6 +585,20 @@ is_cpu_affected() {
_set_vuln retbleed
fi
# VMScape (CVE-2025-40300): AMD families 0x17/0x19/0x1a, Hygon family 0x18
# kernel cpu_vuln_blacklist VMSCAPE (a508cec6e521)
if is_amd; then
if [ "$cpu_family" = $((0x17)) ] || [ "$cpu_family" = $((0x19)) ] || [ "$cpu_family" = $((0x1a)) ]; then
pr_debug "is_cpu_affected: vmscape: AMD family $cpu_family affected"
_set_vuln vmscape
fi
elif is_hygon; then
if [ "$cpu_family" = $((0x18)) ]; then
pr_debug "is_cpu_affected: vmscape: Hygon family $cpu_family affected"
_set_vuln vmscape
fi
fi
elif [ "$cpu_vendor" = CAVIUM ]; then
_set_immune variant3
_set_immune variant3a
@@ -520,12 +741,13 @@ is_cpu_affected() {
_infer_immune itlbmh
fi
# shellcheck disable=SC2154 # affected_zenbleed/inception/retbleed/tsa/downfall/reptar set via eval (_set_immune)
# shellcheck disable=SC2154 # affected_zenbleed/inception/retbleed/tsa/downfall/reptar/its/vmscape/bpi set via eval (_set_immune)
{
pr_debug "is_cpu_affected: final results: variant1=$affected_variant1 variant2=$affected_variant2 variant3=$affected_variant3 variant3a=$affected_variant3a"
pr_debug "is_cpu_affected: final results: variant4=$affected_variant4 variantl1tf=$affected_variantl1tf msbds=$affected_msbds mfbds=$affected_mfbds"
pr_debug "is_cpu_affected: final results: mlpds=$affected_mlpds mdsum=$affected_mdsum taa=$affected_taa itlbmh=$affected_itlbmh srbds=$affected_srbds"
pr_debug "is_cpu_affected: final results: zenbleed=$affected_zenbleed inception=$affected_inception retbleed=$affected_retbleed tsa=$affected_tsa downfall=$affected_downfall reptar=$affected_reptar"
pr_debug "is_cpu_affected: final results: zenbleed=$affected_zenbleed inception=$affected_inception retbleed=$affected_retbleed tsa=$affected_tsa downfall=$affected_downfall reptar=$affected_reptar its=$affected_its"
pr_debug "is_cpu_affected: final results: vmscape=$affected_vmscape bpi=$affected_bpi"
}
affected_variantl1tf_sgx="$affected_variantl1tf"
# even if we are affected to L1TF, if there's no SGX, we're not affected to the original foreshadow

View File

@@ -166,7 +166,7 @@ while [ -n "${1:-}" ]; do
case "$2" in
help)
echo "The following parameters are supported for --variant (can be used multiple times):"
echo "1, 2, 3, 3a, 4, msbds, mfbds, mlpds, mdsum, l1tf, taa, mcepsc, srbds, zenbleed, downfall, inception, reptar, tsa, tsa-sq, tsa-l1"
echo "1, 2, 3, 3a, 4, msbds, mfbds, mlpds, mdsum, l1tf, taa, mcepsc, srbds, zenbleed, downfall, retbleed, inception, reptar, tsa, tsa-sq, tsa-l1, its, vmscape, bpi"
exit 0
;;
1)
@@ -229,6 +229,10 @@ while [ -n "${1:-}" ]; do
opt_cve_list="$opt_cve_list CVE-2022-40982"
opt_cve_all=0
;;
retbleed)
opt_cve_list="$opt_cve_list CVE-2022-29900 CVE-2022-29901"
opt_cve_all=0
;;
inception)
opt_cve_list="$opt_cve_list CVE-2023-20569"
opt_cve_all=0
@@ -249,6 +253,18 @@ while [ -n "${1:-}" ]; do
opt_cve_list="$opt_cve_list CVE-2024-36357"
opt_cve_all=0
;;
its)
opt_cve_list="$opt_cve_list CVE-2024-28956"
opt_cve_all=0
;;
vmscape)
opt_cve_list="$opt_cve_list CVE-2025-40300"
opt_cve_all=0
;;
bpi)
opt_cve_list="$opt_cve_list CVE-2024-45332"
opt_cve_all=0
;;
*)
echo "$0: error: invalid parameter '$2' for --variant, see --variant help for a list" >&2
exit 255

View File

@@ -281,7 +281,7 @@ pr_info
# Sets: ret_sys_interface_check_fullmsg
# Returns: 0 if file matched, 1 otherwise
sys_interface_check() {
local file regex mode msg mockvarname
local file regex mode mockvarname
file="$1"
regex="${2:-}"
mode="${3:-}"
@@ -734,6 +734,7 @@ check_cpu() {
cap_tsx_ctrl_msr=-1
cap_gds_ctrl=-1
cap_gds_no=-1
cap_its_no=-1
if [ "$cap_arch_capabilities" = -1 ]; then
pstatus yellow UNKNOWN
elif [ "$cap_arch_capabilities" != 1 ]; then
@@ -748,6 +749,7 @@ check_cpu() {
cap_tsx_ctrl_msr=0
cap_gds_ctrl=0
cap_gds_no=0
cap_its_no=0
pstatus yellow NO
else
read_msr $MSR_IA32_ARCH_CAPABILITIES
@@ -763,6 +765,7 @@ check_cpu() {
cap_tsx_ctrl_msr=0
cap_gds_ctrl=0
cap_gds_no=0
cap_its_no=0
if [ $ret = $READ_MSR_RET_OK ]; then
capabilities=$ret_read_msr_value
# https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/include/asm/msr-index.h#n82
@@ -778,7 +781,8 @@ check_cpu() {
[ $((ret_read_msr_value_lo >> 8 & 1)) -eq 1 ] && cap_taa_no=1
[ $((ret_read_msr_value_lo >> 25 & 1)) -eq 1 ] && cap_gds_ctrl=1
[ $((ret_read_msr_value_lo >> 26 & 1)) -eq 1 ] && cap_gds_no=1
pr_debug "capabilities says rdcl_no=$cap_rdcl_no ibrs_all=$cap_ibrs_all rsba=$cap_rsba l1dflush_no=$cap_l1dflush_no ssb_no=$cap_ssb_no mds_no=$cap_mds_no taa_no=$cap_taa_no pschange_msc_no=$cap_pschange_msc_no"
[ $((ret_read_msr_value_hi >> 30 & 1)) -eq 1 ] && cap_its_no=1
pr_debug "capabilities says rdcl_no=$cap_rdcl_no ibrs_all=$cap_ibrs_all rsba=$cap_rsba l1dflush_no=$cap_l1dflush_no ssb_no=$cap_ssb_no mds_no=$cap_mds_no taa_no=$cap_taa_no pschange_msc_no=$cap_pschange_msc_no its_no=$cap_its_no"
if [ "$cap_ibrs_all" = 1 ]; then
pstatus green YES
else

View File

@@ -15,8 +15,13 @@ check_CVE_2023_23583_linux() {
# there is no sysfs file for this vuln, and no kernel patch,
# the mitigation is only ucode-based and there's no flag exposed,
# so most of the work has already been done by is_cpu_affected()
# shellcheck disable=SC2154
if ! is_cpu_affected "$cve"; then
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
elif [ -z "$g_reptar_fixed_ucode_version" ]; then
# CPU matched the model blacklist but has no known fixing microcode
# (likely an EOL stepping that Intel won't release a fix for)
pvulnstatus "$cve" VULN "your CPU is affected and no microcode update is available for your CPU stepping"
else
pr_info_nol "* Reptar is mitigated by microcode: "
if [ "$cpu_ucode" -lt "$g_reptar_fixed_ucode_version" ]; then

163
src/vulns/CVE-2024-28956.sh Normal file
View File

@@ -0,0 +1,163 @@
# vim: set ts=4 sw=4 sts=4 et:
###############################
# CVE-2024-28956, ITS, Indirect Target Selection
check_CVE_2024_28956() {
check_cve 'CVE-2024-28956'
}
check_CVE_2024_28956_linux() {
local status sys_interface_available msg kernel_its kernel_its_err ret
status=UNK
sys_interface_available=0
msg=''
if sys_interface_check "$VULN_SYSFS_BASE/indirect_target_selection"; then
# this kernel has the /sys interface, trust it over everything
sys_interface_available=1
#
# Kernel source inventory for indirect_target_selection (ITS)
#
# --- sysfs messages ---
# all versions:
# "Not affected" (cpu_show_common, pre-existing)
#
# --- mainline ---
# f4818881c47f (v6.15-rc2, initial ITS sysfs):
# "Vulnerable" (ITS_MITIGATION_OFF)
# "Mitigation: Aligned branch/return thunks" (ITS_MITIGATION_ALIGNED_THUNKS)
# "Mitigation: Retpolines, Stuffing RSB" (ITS_MITIGATION_RETPOLINE_STUFF)
# 2665281a07e1 (v6.15-rc2, added vmexit option):
# "Mitigation: Vulnerable, KVM: Not affected" (ITS_MITIGATION_VMEXIT_ONLY)
# facd226f7e0c (v6.15-rc2, added stuff cmdline option):
# no string changes; added "stuff" boot param value
# 61ab72c2c6bf (v6.16-rc1, restructured select/update/apply):
# no string changes; added ITS_MITIGATION_AUTO (internal, resolved before display)
# split into its_select_mitigation() + its_update_mitigation() + its_apply_mitigation()
# 0cdd2c4f35cf (v6.18-rc1, attack vector controls):
# no string changes; added per-vector on/off control
#
# --- stable backports ---
# 5.10.y, 5.15.y, 6.1.y: 3 strings only (no VMEXIT_ONLY, no RETPOLINE_STUFF
# in 5.10/5.15/6.1). Uses CONFIG_RETPOLINE/CONFIG_RETHUNK (not CONFIG_MITIGATION_*).
# 6.6.y, 6.12.y, 6.14.y, 6.15.y: all 4 strings, full vmexit+stuff support.
# 6.16.y+: restructured 3-phase select/update/apply.
# Not backported to: 5.4.y, 6.11.y, 6.13.y.
#
# --- RHEL/CentOS ---
# rocky9 (5.14): all 4 strings, restructured 3-phase version.
# rocky10 (6.12): all 4 strings, restructured 3-phase version.
# Not backported to: centos7, rocky8.
#
# --- Kconfig symbols ---
# f4818881c47f (v6.15-rc2): CONFIG_MITIGATION_ITS (default y)
# depends on CPU_SUP_INTEL && X86_64 && MITIGATION_RETPOLINE && MITIGATION_RETHUNK
# stable 5.10.y, 5.15.y, 6.1.y: CONFIG_MITIGATION_ITS
# depends on CONFIG_RETPOLINE && CONFIG_RETHUNK (pre-rename names)
#
# --- kernel functions (for $opt_map / System.map) ---
# f4818881c47f (v6.15-rc2): its_select_mitigation(), its_parse_cmdline(),
# its_show_state()
# 61ab72c2c6bf (v6.16-rc1): split into its_select_mitigation() +
# its_update_mitigation() + its_apply_mitigation()
# stable 5.10.y-6.15.y: its_select_mitigation() (no split)
# rocky9, rocky10: its_select_mitigation() + its_update_mitigation() +
# its_apply_mitigation()
#
# --- CPU affection logic (for is_cpu_affected) ---
# X86_BUG_ITS is set when ALL conditions are true:
# 1. Intel vendor, family 6
# 2. CPU matches model blacklist (with stepping constraints)
# 3. ARCH_CAP_ITS_NO (bit 62 of IA32_ARCH_CAPABILITIES) is NOT set
# 4. X86_FEATURE_BHI_CTRL is NOT present
# 159013a7ca18 (v6.15-rc2, initial model list):
# Intel: SKYLAKE_X (stepping > 5), KABYLAKE_L (stepping > 0xb),
# KABYLAKE (stepping > 0xc), ICELAKE_L, ICELAKE_D, ICELAKE_X,
# COMETLAKE, COMETLAKE_L, TIGERLAKE_L, TIGERLAKE, ROCKETLAKE
# (all steppings unless noted)
# ITS_NATIVE_ONLY flag (X86_BUG_ITS_NATIVE_ONLY): set for
# ICELAKE_L, ICELAKE_D, ICELAKE_X, TIGERLAKE_L, TIGERLAKE, ROCKETLAKE
# These CPUs are affected for user-to-kernel but NOT guest-to-host (VMX)
# immunity: ARCH_CAP_ITS_NO (bit 62 of IA32_ARCH_CAPABILITIES)
# immunity: X86_FEATURE_BHI_CTRL (none of the affected CPUs have this)
# vendor scope: Intel only
#
# all messages start with either "Not affected", "Vulnerable", or "Mitigation"
status=$ret_sys_interface_check_status
fi
if [ "$opt_sysfs_only" != 1 ]; then
pr_info_nol "* Kernel supports ITS mitigation: "
kernel_its=''
kernel_its_err=''
if [ -n "$g_kernel_err" ]; then
kernel_its_err="$g_kernel_err"
elif grep -q 'indirect_target_selection' "$g_kernel"; then
kernel_its="found indirect_target_selection in kernel image"
fi
if [ -z "$kernel_its" ] && [ -r "$opt_config" ]; then
if grep -q '^CONFIG_MITIGATION_ITS=y' "$opt_config"; then
kernel_its="ITS mitigation config option found enabled in kernel config"
fi
fi
if [ -z "$kernel_its" ] && [ -n "$opt_map" ]; then
if grep -q 'its_select_mitigation' "$opt_map"; then
kernel_its="found its_select_mitigation in System.map"
fi
fi
if [ -n "$kernel_its" ]; then
pstatus green YES "$kernel_its"
elif [ -n "$kernel_its_err" ]; then
pstatus yellow UNKNOWN "$kernel_its_err"
else
pstatus yellow NO
fi
pr_info_nol "* CPU explicitly indicates not being affected by ITS (ITS_NO): "
if [ "$cap_its_no" = -1 ]; then
pstatus yellow UNKNOWN
elif [ "$cap_its_no" = 1 ]; then
pstatus green YES
else
pstatus yellow NO
fi
elif [ "$sys_interface_available" = 0 ]; then
# we have no sysfs but were asked to use it only!
msg="/sys vulnerability interface use forced, but it's not available!"
status=UNK
fi
if ! is_cpu_affected "$cve"; then
# override status & msg in case CPU is not vulnerable after all
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
elif [ -z "$msg" ]; then
# if msg is empty, sysfs check didn't fill it, rely on our own test
if [ "$opt_sysfs_only" != 1 ]; then
if [ "$cap_its_no" = 1 ]; then
pvulnstatus "$cve" OK "CPU is not affected (ITS_NO)"
elif [ -n "$kernel_its" ]; then
pvulnstatus "$cve" OK "Kernel mitigates the vulnerability"
elif [ -z "$kernel_its" ] && [ -z "$kernel_its_err" ]; then
pvulnstatus "$cve" VULN "Your kernel doesn't support ITS mitigation"
explain "Update your kernel to a version that includes ITS mitigation (Linux 6.15+, or check\n" \
"if your distro has a backport). Also update your CPU microcode to ensure IBPB fully\n" \
"flushes indirect branch predictions (microcode-20250512+)."
else
pvulnstatus "$cve" UNK "couldn't determine mitigation status: $kernel_its_err"
fi
else
pvulnstatus "$cve" "$status" "$ret_sys_interface_check_fullmsg"
fi
else
pvulnstatus "$cve" "$status" "$msg"
fi
}
check_CVE_2024_28956_bsd() {
if ! is_cpu_affected "$cve"; then
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
else
pvulnstatus "$cve" UNK "your CPU is affected, but mitigation detection has not yet been implemented for BSD in this script"
fi
}

View File

@@ -0,0 +1,53 @@
# vim: set ts=4 sw=4 sts=4 et:
###############################
# CVE-2024-45332, BPI, Branch Privilege Injection
check_CVE_2024_45332() {
check_cve 'CVE-2024-45332'
}
check_CVE_2024_45332_linux() {
local status sys_interface_available msg
status=UNK
sys_interface_available=0
msg=''
# There is no dedicated sysfs file for this vulnerability, and no kernel
# mitigation code. The fix is purely a microcode update that corrects the
# asynchronous branch predictor update timing so that eIBRS and IBPB work
# as originally intended. There is no new CPUID bit, MSR bit, or ARCH_CAP
# flag to detect the fix, so we hardcode known-fixing microcode versions
# per CPU (see bpi_ucode_list in is_cpu_affected).
# shellcheck disable=SC2154
if ! is_cpu_affected "$cve"; then
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
elif [ -z "$g_bpi_fixed_ucode_version" ]; then
# CPU matched the model blacklist but has no known fixing microcode
# (likely an EOL stepping that Intel won't release a fix for)
pvulnstatus "$cve" VULN "your CPU is affected and no microcode update is available for your CPU stepping"
explain "CVE-2024-45332 (Branch Privilege Injection) is a race condition in the branch predictor\n" \
"that undermines eIBRS and IBPB protections. The fix is a microcode update, but no\n" \
"update is available for your specific CPU stepping."
else
pr_info_nol "* BPI is mitigated by microcode: "
if [ "$cpu_ucode" -lt "$g_bpi_fixed_ucode_version" ]; then
pstatus yellow NO "You have ucode $(printf "0x%x" "$cpu_ucode") and version $(printf "0x%x" "$g_bpi_fixed_ucode_version") minimum is required"
pvulnstatus "$cve" VULN "Your microcode is too old to mitigate the vulnerability"
explain "CVE-2024-45332 (Branch Privilege Injection) is a race condition in the branch predictor\n" \
"that undermines eIBRS and IBPB protections. The fix is a microcode update only.\n" \
"No kernel changes are required."
else
pstatus green YES "You have ucode $(printf "0x%x" "$cpu_ucode") which is recent enough (>= $(printf "0x%x" "$g_bpi_fixed_ucode_version"))"
pvulnstatus "$cve" OK "Your microcode mitigates the vulnerability"
fi
fi
}
check_CVE_2024_45332_bsd() {
if ! is_cpu_affected "$cve"; then
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
else
pvulnstatus "$cve" UNK "your CPU is affected, but mitigation detection has not yet been implemented for BSD in this script"
fi
}

147
src/vulns/CVE-2025-40300.sh Normal file
View File

@@ -0,0 +1,147 @@
# vim: set ts=4 sw=4 sts=4 et:
###############################
# CVE-2025-40300, VMScape, VM-Exit Stale Branch Prediction
check_CVE_2025_40300() {
check_cve 'CVE-2025-40300'
}
check_CVE_2025_40300_linux() {
local status sys_interface_available msg kernel_vmscape kernel_vmscape_err
status=UNK
sys_interface_available=0
msg=''
if sys_interface_check "$VULN_SYSFS_BASE/vmscape"; then
# this kernel has the /sys interface, trust it over everything
sys_interface_available=1
#
# Kernel source inventory for vmscape, traced via git blame:
#
# --- sysfs messages ---
# all versions:
# "Not affected" (cpu_show_common, pre-existing)
#
# --- mainline ---
# a508cec6e521 (v6.17-rc6, initial vmscape sysfs):
# "Vulnerable" (VMSCAPE_MITIGATION_NONE)
# "Mitigation: IBPB before exit to userspace" (VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
# 2f8f17341 (v6.17-rc6, vmscape_update_mitigation):
# "Mitigation: IBPB on VMEXIT" (VMSCAPE_MITIGATION_IBPB_ON_VMEXIT)
# (when retbleed uses IBPB or srso uses IBPB_ON_VMEXIT)
#
# --- stable backports ---
# 6.16.x (v6.16.7): identical to mainline (d83e6111337f)
# 6.12.x (v6.12.47): identical to mainline (7c62c442b6eb)
# 6.6.x (v6.6.106): identical to mainline (813cb831439c)
# 6.1.x (v6.1.152): identical strings; uses VULNBL_INTEL_STEPPINGS macro,
# missing ARROWLAKE_U, ATOM_CRESTMONT_X, AMD 0x1a.
# Uses ALDERLAKE_N instead of type-specific ALDERLAKE split. (304d1fb275af)
#
# --- RHEL/CentOS ---
# Not yet backported.
#
# --- Kconfig symbols ---
# a508cec6e521 (v6.17-rc6): CONFIG_MITIGATION_VMSCAPE (default y)
# depends on KVM
#
# --- kernel functions (for $opt_map / System.map) ---
# a508cec6e521 (v6.17-rc6): vmscape_select_mitigation(),
# vmscape_update_mitigation(), vmscape_apply_mitigation(),
# vmscape_parse_cmdline(), vmscape_show_state()
#
# --- CPU affection logic (for is_cpu_affected) ---
# X86_BUG_VMSCAPE is set when ALL conditions are true:
# 1. CPU matches model blacklist
# 2. X86_FEATURE_HYPERVISOR is NOT set (bare metal only)
# a508cec6e521 (v6.17-rc6, initial model list):
# Intel: SKYLAKE_X, SKYLAKE_L, SKYLAKE, KABYLAKE_L, KABYLAKE,
# CANNONLAKE_L, COMETLAKE, COMETLAKE_L, ALDERLAKE,
# ALDERLAKE_L, RAPTORLAKE, RAPTORLAKE_P, RAPTORLAKE_S,
# METEORLAKE_L, ARROWLAKE_H, ARROWLAKE, ARROWLAKE_U,
# LUNARLAKE_M, SAPPHIRERAPIDS_X, GRANITERAPIDS_X,
# EMERALDRAPIDS_X, ATOM_GRACEMONT, ATOM_CRESTMONT_X
# AMD: family 0x17 (Zen 1/+/2), family 0x19 (Zen 3/4),
# family 0x1a (Zen 5)
# Hygon: family 0x18
# 8a68d64bb103 (v6.17-rc6, added old Intel CPUs):
# Intel: + SANDYBRIDGE_X, SANDYBRIDGE, IVYBRIDGE_X, IVYBRIDGE,
# HASWELL, HASWELL_L, HASWELL_G, HASWELL_X,
# BROADWELL_D, BROADWELL_X, BROADWELL_G, BROADWELL
# Intel NOT affected: ICELAKE_*, TIGERLAKE_*, LAKEFIELD, ROCKETLAKE,
# ATOM_TREMONT_*, ATOM_GOLDMONT_*
# immunity: no ARCH_CAP bits — determination is purely via blacklist
# note: bare metal only (X86_FEATURE_HYPERVISOR excludes guests)
# vendor scope: Intel + AMD + Hygon
#
# all messages start with either "Not affected", "Vulnerable", or "Mitigation"
status=$ret_sys_interface_check_status
fi
if [ "$opt_sysfs_only" != 1 ]; then
check_has_vmm
pr_info_nol "* Kernel supports VMScape mitigation: "
kernel_vmscape=''
kernel_vmscape_err=''
if [ -n "$g_kernel_err" ]; then
kernel_vmscape_err="$g_kernel_err"
elif grep -q 'vmscape' "$g_kernel"; then
kernel_vmscape="found vmscape in kernel image"
fi
if [ -z "$kernel_vmscape" ] && [ -r "$opt_config" ]; then
if grep -q '^CONFIG_MITIGATION_VMSCAPE=y' "$opt_config"; then
kernel_vmscape="VMScape mitigation config option found enabled in kernel config"
fi
fi
if [ -z "$kernel_vmscape" ] && [ -n "$opt_map" ]; then
if grep -q 'vmscape_select_mitigation' "$opt_map"; then
kernel_vmscape="found vmscape_select_mitigation in System.map"
fi
fi
if [ -n "$kernel_vmscape" ]; then
pstatus green YES "$kernel_vmscape"
elif [ -n "$kernel_vmscape_err" ]; then
pstatus yellow UNKNOWN "$kernel_vmscape_err"
else
pstatus yellow NO
fi
elif [ "$sys_interface_available" = 0 ]; then
# we have no sysfs but were asked to use it only!
msg="/sys vulnerability interface use forced, but it's not available!"
status=UNK
fi
if ! is_cpu_affected "$cve"; then
# override status & msg in case CPU is not vulnerable after all
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
elif [ -z "$msg" ]; then
# if msg is empty, sysfs check didn't fill it, rely on our own test
if [ "$opt_sysfs_only" != 1 ]; then
if [ "$g_has_vmm" = 0 ]; then
pvulnstatus "$cve" OK "this system is not running a hypervisor"
elif [ -n "$kernel_vmscape" ]; then
pvulnstatus "$cve" OK "Kernel mitigates the vulnerability"
elif [ -z "$kernel_vmscape" ] && [ -z "$kernel_vmscape_err" ]; then
pvulnstatus "$cve" VULN "Your kernel doesn't support VMScape mitigation"
explain "Update your kernel to a version that includes the VMScape mitigation (Linux 6.18+, or check\n" \
"if your distro has a backport). The mitigation issues IBPB before returning to userspace\n" \
"after a VM exit, preventing stale guest branch predictions from leaking host kernel memory."
else
pvulnstatus "$cve" UNK "couldn't determine mitigation status: $kernel_vmscape_err"
fi
else
pvulnstatus "$cve" "$status" "$ret_sys_interface_check_fullmsg"
fi
else
pvulnstatus "$cve" "$status" "$msg"
fi
}
check_CVE_2025_40300_bsd() {
if ! is_cpu_affected "$cve"; then
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
else
pvulnstatus "$cve" UNK "your CPU is affected, but mitigation detection has not yet been implemented for BSD in this script"
fi
}