arm64: add SSBS detection

built from commit 737cfe4a5f
 dated 2026-06-06 17:01:46 +0200
 by Stéphane Lesimple (speed47_github@speed47.net)

FAQ.md

@@ -1,145 +0,0 @@
-# Questions
-
-- [What to expect from this tool?](#what-to-expect-from-this-tool)
-- [Why was this script written in the first place?](#why-was-this-script-written-in-the-first-place)
-- [Why are those vulnerabilities so different than regular CVEs?](#why-are-those-vulnerabilities-so-different-than-regular-cves)
-- [What do "affected", "vulnerable" and "mitigated" mean exactly?](#what-do-affected-vulnerable-and-mitigated-mean-exactly)
-- [What are the main design decisions regarding this script?](#what-are-the-main-design-decisions-regarding-this-script)
-- [Everything is indicated in `sysfs` now, is this script still useful?](#everything-is-indicated-in-sysfs-now-is-this-script-still-useful)
-- [How does this script work?](#how-does-this-script-work)
-- [Which BSD OSes are supported?](#which-bsd-oses-are-supported)
-- [Why is my OS not supported?](#why-is-my-os-not-supported)
-- [The tool says there is an updated microcode for my CPU, but I don't have it!](#the-tool-says-there-is-an-updated-microcode-for-my-cpu-but-i-dont-have-it)
-- [The tool says that I need a more up-to-date microcode, but I have the more recent version!](#the-tool-says-that-i-need-a-more-up-to-date-microcode-but-i-have-the-more-recent-version)
-- [Which rules are governing the support of a CVE in this tool?](#which-rules-are-governing-the-support-of-a-cve-in-this-tool)
-
-# Answers
-
-## What to expect from this tool?
-
-This tool does its best to determine where your system stands on each of the collectively named [transient execution](https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability) vulnerabilities (also sometimes called "speculative execution" vulnerabilities) that were made public since early 2018. It doesn't attempt to run any kind of exploit, and can't guarantee that your system is secure, but rather helps you verifying if your system is affected, and if it is, checks whether it has the known mitigations in place to avoid being vulnerable.
-Some mitigations could also exist in your kernel that this script doesn't know (yet) how to detect, or it might falsely detect mitigations that in the end don't work as expected (for example, on backported or modified kernels).
-
-Please also note that for Spectre vulnerabilities, all software can possibly be exploited, this tool only verifies that the kernel (which is the core of the system) you're using has the proper protections in place. Verifying all the other software is out of the scope of this tool. As a general measure, ensure you always have the most up to date stable versions of all the software you use, especially for those who are exposed to the world, such as network daemons and browsers.
-
-This tool has been released in the hope that it'll be useful, but don't use it to jump to definitive conclusions about your security: hardware vulnerabilities are [complex beasts](#why-are-those-vulnerabilities-so-different-than-regular-cves), and collective understanding of each vulnerability is evolving with time.
-
-## Why was this script written in the first place?
-
-The first commit of this script is dated *2018-01-07*, only 4 days after the world first heard about the Meltdown and the Spectre attacks. With those attacks disclosure, a _whole new range of vulnerabilities_ that were previously thought to be mostly theoretical and only possible in very controlled environments (labs) - hence of little interest for most except researchers - suddenly became completely mainstream and apparently trivial to conduct on an immensely large number of systems.
-
-On the few hours and days after that date, the whole industry went crazy. Proper, verified information about these vulnerabilities was incredibly hard to find, because before this, even the CPU vendors never had to deal with managing security vulnerabilities at scale, as software vendors do since decades. There were a lot of FUD, and the apparent silence of the vendors was enough for most to fear the worst. The whole industry had everything to learn about this new type of vulnerabilities. However, most systems administrators had a few simple questions:
-
-- Am **I** vulnerable? And if yes,
-- What do I have to do to mitigate these vulnerabilities on **my** system?
-
-Unfortunately, answering those questions was very difficult (and still is to some extent), even if the safe answer to the first question was "you probably are". This script was written to try to give simple answers to those simple questions, and was made to evolve as the information about these vulnerabilities became available. On the first few days, there was several new versions published **per day**.
-
-## Why are those vulnerabilities so different than regular CVEs?
-
-Those are hardware vulnerabilities, while most of the CVEs we see everyday are software vulnerabilities. A quick comparison would be:
-
-Software vulnerability:
-- Can be fixed? Yes.
-- How to fix? Update the software (or uninstall it!)
-
-Hardware vulnerability:
-- Can be fixed? No, only mitigated (or buy new hardware!)
-- How to ~~fix~~ mitigate? In the worst case scenario, 5 "layers" need to be updated: the microcode/firmware, the host OS kernel, the hypervisor, the VM OS kernel, and possibly all the software running on the machine. Sometimes only a subset of those layers need to be updated. In yet other cases, there can be several possible mitigations for the same vulnerability, implying different layers. Yes, it can get horribly complicated.
-
-A more detailed video explanation is available here: https://youtu.be/2gB9U1EcCss?t=425
-
-## What do "affected", "vulnerable" and "mitigated" mean exactly?
-
-- **Affected** means that your CPU's hardware, as it went out of the factory, is known to be concerned by a specific vulnerability, i.e. the vulnerability applies to your hardware model. Note that it says nothing about whether a given vulnerability can actually be used to exploit your system. However, an unaffected CPU will never be vulnerable, and doesn't need to have mitigations in place.
-- **Vulnerable** implies that you're using an **affected** CPU, and means that a given vulnerability can be exploited on your system, because no (or insufficient) mitigations are in place.
-- **Mitigated** implies that a previously **vulnerable** system has followed all the steps (updated all the required layers) to ensure a given vulnerability cannot be exploited. About what "layers" mean, see [the previous question](#why-are-those-vulnerabilities-so-different-than-regular-cves).
-
-## What are the main design decisions regarding this script?
-
-There are a few rules that govern how this tool is written.
-
-1) It should be okay to run this script in a production environment. This implies, but is not limited to:
-
-   * 1a. Never modify the system it's running on, and if it needs to e.g. load a kernel module it requires, that wasn't loaded before it was launched, it'll take care to unload it on exit
-   * 1b. Never attempt to "fix" or "mitigate" any vulnerability, or modify any configuration. It just reports what it thinks is the status of your system. It leaves all decisions to the sysadmin.
-   * 1c. Never attempt to run any kind of exploit to tell whether a vulnerability is mitigated, because it would violate 1a), could lead to unpredictable system behavior, and might even lead to wrong conclusions, as some PoC must be compiled with specific options and prerequisites, otherwise giving wrong information (especially for Spectre). If you want to run PoCs, do it yourself, but please read carefully about the PoC and the vulnerability. PoCs about a hardware vulnerability are way more complicated and prone to false conclusions than PoCs for software vulnerabilities.
-
-2) Never look at the kernel version to tell whether it supports mitigation for a given vulnerability. This implies never hardcoding version numbers in the script. This would defeat the purpose: this script should be able to detect mitigations in unknown kernels, with possibly backported or forward-ported patches. Also, don't believe what `sysfs` says, when possible. See the next question about this.
-
-3) Never look at the microcode version to tell whether it has the proper mechanisms in place to support mitigation for a given vulnerability. This implies never hardcoding version numbers in the script. Instead, look for said mechanisms, as the kernel would do.
-
-4) When a CPU is not known to be explicitly unaffected by a vulnerability, make the assumption that it is. This strong design choice has it roots in the early speculative execution vulnerability days (see [this answer](#why-was-this-script-written-in-the-first-place)), and is still a good approach as of today.
-
-## Everything is indicated in `sysfs` now, is this script still useful?
-
-A lot as changed since 2018. Nowadays, the industry adapted and this range of vulnerabilities is almost "business as usual", as software vulnerabilities are. However, due to their complexity, it's still not as easy as just checking a version number to ensure a vulnerability is closed.
-
-Granted, we now have a standard way under Linux to check whether our system is affected, vulnerable, mitigated against most of these vulnerabilities. By having a look at the `sysfs` hierarchy, and more precisely the `/sys/devices/system/cpu/vulnerabilities/` folder, one can have a pretty good insight about its system state for each of the listed vulnerabilities. Note that the output can be a little different with some vendors (e.g. Red Hat has some slightly different output than the vanilla kernel for some vulnerabilities), but it's still a gigantic leap forward, given where we were in 2018 when this script was started, and it's very good news. The kernel is the proper place to have this because the kernel knows everything about itself (the mitigations it might have), and the CPU (its model, and microcode features that are exposed). Note however that some vulnerabilities are not reported through this file hierarchy at all, such as Zenbleed.
-
-However I see a few reasons why this script might still be useful to you, and that's why its development has not halted when the `sysfs` hierarchy came out:
-
-- A given version of the kernel doesn't have knowledge about the future. To put it in another way: a given version of the kernel only has the understanding of a vulnerability available at the time it was compiled. Let me explain this: when a new vulnerability comes out, new versions of the microcode and kernels are released, with mitigations in place. With such a kernel, a new `sysfs` entry will appear. However, after a few weeks or months, corner cases can be discovered, previously-thought unaffected CPUs can turn out to be affected in the end, and sometimes mitigations can end up being insufficient.  Of course, if you're always running the latest kernel version from kernel.org, this issue might be limited for you. The spectre-meltdown-checker script doesn't depend on a kernel's knowledge and understanding of a vulnerability to compute its output. That is, unless you tell it to (using the `--sysfs-only` option).
-
-- Mitigating a vulnerability completely can sometimes be tricky, and have a lot of complicated prerequisites, depending on your kernel version, CPU vendor, model and even sometimes stepping, CPU microcode, hypervisor support, etc. The script gives a very detailed insight about each of the prerequisites of mitigation for every vulnerability, step by step, hence pointing out what is missing on your system as a whole to completely mitigate an issue.
-
-- The script can be pointed at a kernel image, and will deep dive into it, telling you if this kernel will mitigate vulnerabilities that might be present on your system. This is a good way to verify before booting a new kernel, that it'll mitigate the vulnerabilities you expect it to, especially if you modified a few config options around these topics.
-
-- The script will also work regardless of the custom patches that might be integrated in the kernel you're running (or you're pointing it to, in offline mode), and completely ignores the advertised kernel version, to tell whether a given kernel mitigates vulnerabilities. This is especially useful for non-vanilla kernel, where patches might be backported, sometimes silently (this has already happened, too).
-
-- Educational purposes: the script gives interesting insights about a vulnerability, and how the different parts of the system work together to mitigate it.
-
-There are probably other reasons, but that are the main ones that come to mind. In the end, of course, only you can tell whether it's useful for your use case ;)
-
-## How does this script work?
-
-On one hand, the script gathers information about your CPU, and the features exposed by its microcode. To do this, it uses the low-level CPUID instruction (through the `cpuid` kernel module under Linux, and the `cpucontrol` tool under BSD), and queries to the MSR registers of your CPU (through the `msr` kernel module under Linux, and the `cpucontrol` tool under BSD).
-
-On another hand, the script looks into the kernel image your system is running on, for clues about the mitigations it supports. Of course, this is very specific for each operating system, even if the implemented mitigation is functionally the same, the actual code is completely specific. As you can imagine, the Linux kernel code has a few in common with a BSD kernel code, for example. Under Linux, the script supports looking into the kernel image, and possibly the System.map and kernel config file, if these are available. Under BSD, it looks into the kernel file only.
-
-Then, for each vulnerability it knows about, the script decides whether your system is [affected, vulnerable, and mitigated](#what-do-affected-vulnerable-and-mitigated-mean-exactly) against it, using the information it gathered about your hardware and your kernel.
-
-## Which BSD OSes are supported?
-
-For the BSD range of operating systems, the script will work as long as the BSD you're using supports `cpuctl` and `linprocfs`. This is not the case for OpenBSD for example. Known BSD flavors having proper support are: FreeBSD, NetBSD, DragonflyBSD. Derivatives of those should also work. To know why other BSDs will likely never be supported, see [why is my OS not supported?](#why-is-my-os-not-supported).
-
-## Why is my OS not supported?
-
-This tool only supports Linux, and [some flavors of BSD](#which-bsd-oses-are-supported). Other OSes will most likely never be supported, due to [how this script works](#how-does-this-script-work). It would require implementing these OSes specific way of querying the CPU. It would also require to get documentation (if available) about how this OS mitigates each vulnerability, down to this OS kernel code, and if documentation is not available, reverse-engineer the difference between a known old version of a kernel, and a kernel that mitigates a new vulnerability. This means that all the effort has to be duplicated times the number of supported OSes, as everything is specific, by construction. It also implies having a deep understanding of every OS, which takes years to develop. However, if/when other tools appear for other OSes, that share the same goal of this one, they might be listed here as a convenience.
-
-## The tool says there is an updated microcode for my CPU, but I don't have it!
-
-Even if your operating system is fully up to date, the tool might still tell you that there is a more recent microcode version for your CPU. Currently, it uses (and merges) information from 4 sources:
-
-- The official [Intel microcode repository](https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files)
-- The awesome platomav's [MCExtractor database](https://github.com/platomav/MCExtractor) for non-Intel CPUs
-- The official [linux-firmware](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git) repository for AMD
-- Specific Linux kernel commits that sometimes hardcode microcode versions, such as for [Zenbleed](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98) or for the bad [Spectre](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/intel.c#n141) microcodes
-
-Generally, it means a more recent version of the microcode has been seen in the wild. However, fully public availability of this microcode might be limited yet, or your OS vendor might have chosen not to ship this new version (yet), maybe because it's currently being tested, or for other reasons. This tool can't tell you when or if this will be the case. You should ask your vendor about it. Technically, you can still go and upgrade your microcode yourself, and use this tool to confirm whether you did it successfully. Updating the microcode for you is out of the scope of this tool, as this would violate [rule 1b](#what-are-the-main-design-decisions-regarding-this-script).
-
-## The tool says that I need a more up-to-date microcode, but I have the more recent version!
-
-This can happen for a few reasons:
-
-- Your CPU is no longer supported by the vendor. In that case, new versions of the microcode will never be published, and vulnerabilities requiring microcode features will never be fixed. On most of these vulnerabilities, you'll have no way to mitigate the issue on a vulnerable system, appart from buying a more recent CPU. Sometimes, you might be able to mitigate the issue by disabling a CPU feature instead (often at the cost of speed). When this is the case, the script will list this as one of the possible mitigations for the vulnerability.
-
-- The vulnerability is recent, and your CPU has not yet received a microcode update for the vendor. Often, these updates come in batches, and it can take several batches to cover all the supported CPUs.
-
-In both cases, you can contact your vendor to know whether there'll be an update or not, and if yes, when. For Intel, at the time this FAQ entry was written, such guidance was [available here](https://software.intel.com/content/www/us/en/develop/topics/software-security-guidance/processors-affected-consolidated-product-cpu-model.html).
-
-## Which rules are governing the support of a CVE in this tool?
-
-On the early days, it was easy: just Spectre and Meltdown (hence the tool name), because that's all we had. Now that this range of vulnerability is seeing a bunch of newcomers every year, this question is legitimate.
-
-To stick with this tool's goal, a good indication as to why a CVE should be supported, is when mitigating it requires either kernel modifications, microcode modifications, or both.
-
-Counter-examples include (non-exhaustive list):
-
-- [CVE-2019-14615](https://github.com/speed47/spectre-meltdown-checker/issues/340), mitigating this issue is done by updating the Intel driver. This is out of the scope of this tool.
-- [CVE-2019-15902](https://github.com/speed47/spectre-meltdown-checker/issues/304), this CVE is due to a bad backport in the stable kernel. If the faulty backport was part of the mitigation of another supported CVE, and this bad backport was detectable (without hardcoding kernel versions, see [rule 2](#why-are-those-vulnerabilities-so-different-than-regular-cves)), it might have been added as a bullet point in the concerned CVE's section in the tool. However, this wasn't the case.
-- The "[Take A Way](https://github.com/speed47/spectre-meltdown-checker/issues/344)" vulnerability, AMD said that they believe this is not a new attack, hence there were no microcode and no kernel modification made. As there is nothing to look for, this is out of the scope of this tool.
-- [CVE-2020-0550](https://github.com/speed47/spectre-meltdown-checker/issues/347), the vendor thinks this is hardly exploitable in the wild, and as mitigations would be too performance impacting, as a whole the industry decided to not address it. As there is nothing to check for, this is out of the scope of this tool.
-- [CVE-2020-0551](https://github.com/speed47/spectre-meltdown-checker/issues/348), the industry decided to not address it, as it is believed mitigations for other CVEs render this attack practically hard to make, Intel just released an updated SDK for SGX to help mitigate the issue, but this is out of the scope of this tool.
-
-Look for the [information](https://github.com/speed47/spectre-meltdown-checker/issues?q=is%3Aissue+is%3Aopen+label%3Ainformation) tag in the issues list for more examples.

doc/UNSUPPORTED_CVE_LIST.md

@@ -188,6 +188,18 @@ Observable timing discrepancy in some Intel processors allows an authenticated u
 
 **Why out of scope:** Like CVE-2020-24511, this is a microcode-only fix with no Linux kernel sysfs entry, no CPUID bit, no MSR, and no kernel configuration option. Detection would require a per-CPU-stepping microcode version lookup table. The vulnerability has low severity (CVSS 2.8) and practical exploitation is limited. Intel dropped microcode support for Sandy Bridge and Ivy Bridge, leaving those generations permanently vulnerable.
 
+## CVE-2021-26314 / CVE-2021-26313 — Floating-Point Value Injection (FPVI) and Speculative Code Store Bypass (SCSB)
+
+- **Bulletin:** [AMD-SB-1003](https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1003.html) (FPVI and SCSB); [AMD-SB-7050](https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7050.html) (FPVI variant, informational)
+- **Intel advisory:** [Floating Point Value Injection](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/floating-point-value-injection.html)
+- **Research paper:** [Rage Against the Machine Clear (FPVI/SCSB) — VUSec, USENIX Security '21](https://www.vusec.net/projects/fpvi-scsb/)
+- **Affected CPUs:** All supported AMD CPU products; Intel CPUs (FPVI)
+- **CVSS:** 5.5 (Medium) for both
+
+FPVI (CVE-2021-26314) lets an attacker inject arbitrary floating-point values into the transient execution window opened by a floating-point machine clear, so that dependent operations transiently compute on attacker-influenced values that can then be inferred through a microarchitectural covert channel. SCSB (CVE-2021-26313) is the companion vulnerability where overwritten instructions may still be executed speculatively. AMD-SB-7050 documents an FPVI variant (from the "TREVEX" detection-framework paper) that can be triggered without denormal inputs; AMD considers it to fall within the existing scope of CVE-2021-26314 and assigned it no new CVE, classifying it as informational only.
+
+**Why out of scope:** The mitigation responsibility falls on individual software, not on the kernel or microcode. Both AMD and Intel recommend that software vendors analyze their code for vulnerable speculative floating-point sequences and insert an `LFENCE` to serialize execution. No microcode update, no CPUID flag, no MSR, and no kernel configuration option was issued, and there is no `/sys/devices/system/cpu/vulnerabilities/` entry for FPVI or SCSB — the kernel never added one, because the fix is not a kernel-level control. This is the same situation as [SLAM (CVE-2020-12965)](#cve-2020-12965--transient-execution-of-non-canonical-accesses-slam) and "Take A Way": the vendor's guidance is "software inserts LFENCE in its own code," leaving nothing for this tool to check. The AMD-SB-7050 variant adds nothing detectable, as it is informational and reuses the existing (software-only) FPVI guidance.
+
 ## CVE-2021-26318 — AMD Prefetch Attacks through Power and Time
 
 - **Issue:** [#412](https://github.com/speed47/spectre-meltdown-checker/issues/412)
@@ -308,6 +320,28 @@ Exploits a synchronization failure in the AMD stack engine via an undocumented M
 
 **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.
 
+## CVE-2025-52533 — AMD On-Chip Debug Interface Improper Access Control
+
+- **Advisory:** [NVD CVE-2025-52533](https://nvd.nist.gov/vuln/detail/CVE-2025-52533)
+- **Affected CPUs:** AMD (various; on-chip debug/test interface)
+- **CVSS:** 8.7 (High)
+- **CWE:** [CWE-1191 (On-Chip Debug and Test Interface With Improper Access Control)](https://cwe.mitre.org/data/definitions/1191.html)
+
+Improper access control in an on-chip debug interface could allow a privileged attacker to enable a debug interface and potentially compromise data confidentiality or integrity.
+
+**Why out of scope:** Not a transient or speculative execution vulnerability — this is an access-control flaw in a hardware debug/test interface (CWE-1191), with no side-channel or speculative execution component, and it requires a privileged attacker. There is no Linux kernel sysfs entry, no CPUID flag, and no kernel-side mitigation: the fix is delivered as platform/PSP firmware and proven via remote attestation against AMD's Key Distribution Service (KDS), with several SKUs marked "no fix planned." None of this is detectable by this tool, which inspects OS-loadable microcode revisions, CPUID/MSR bits, kernel capabilities, and sysfs.
+
+## CVE-2026-46174 — AMD Zen 2 Op Cache Improper Resource Isolation
+
+- **Bulletin:** [AMD-SB-7052](https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7052.html) (CPU OP Cache Corruption)
+- **Kernel fix:** [commit 1e23b30a80b1](https://github.com/torvalds/linux/commit/1e23b30a80b14e5764657401ee2cca030525ae8e) — `x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache`
+- **Affected CPUs:** AMD Zen 2
+- **CVSS:** 8.8 (High)
+
+Resources in the Zen 2 micro-op (op) cache can be improperly shared, causing instruction corruption that may be leveraged to execute instructions at a higher privilege level (userspace-to-kernel escalation). The Linux fix sets a bug-fix bit (bit 33) in the AMD `BP_CFG` model-specific register (`0xc001102e`) via `msr_set_bit()` in `init_amd_zen2()`, and only on bare metal (skipped when `X86_FEATURE_HYPERVISOR` is set, as the mitigation is the host's responsibility for guests).
+
+**Why out of scope:** Not a transient or speculative execution vulnerability — this is an op-cache resource-isolation bug that causes *instruction corruption* (an integrity/correctness erratum), with no side-channel or speculative data-leak component, which places it outside the vulnerability class this tool detects. It is also undetectable by this tool's standard framework: the kernel deliberately adds no `/sys/devices/system/cpu/vulnerabilities/` entry, no `X86_BUG_*` flag (so nothing in `/proc/cpuinfo`), no dmesg message, and no kernel command-line parameter. The mitigation is an unconditional inline MSR bit-set with no greppable named symbol, so it leaves no handle for no-runtime (kernel image / `System.map`) detection. The only possible check would be a live read of `BP_CFG` bit 33, which requires root and the `msr` module, works on bare metal only (guests report `N/A`), and would be a bespoke one-off outside the established CVE-detection model — the same situation as the [JCC Erratum](#no-cve--jump-conditional-code-jcc-erratum) below, but for AMD.
+
 ## No CVE — Jump Conditional Code (JCC) Erratum
 
 - **Issue:** [#329](https://github.com/speed47/spectre-meltdown-checker/issues/329)

spectre-meltdown-checker.sh

@@ -13,7 +13,7 @@
 #
 # Stephane Lesimple
 #
-VERSION='26.36.0601873'
+VERSION='26.36.0606627'
 
 # --- Common paths and basedirs ---
 readonly VULN_SYSFS_BASE="/sys/devices/system/cpu/vulnerabilities"
@@ -3936,11 +3936,18 @@ parse_cpu_details() {
         # cpu_variant_list and cpu_revision_list are consumed by ARM64 errata affection checks
         # that need to match a specific revision range.
         if grep -q 'CPU implementer' "$g_procfs/cpuinfo"; then
-            cpu_impl_list=$(awk '/CPU implementer/ {print $4}' "$g_procfs/cpuinfo")
-            cpu_part_list=$(awk '/CPU part/         {print $4}' "$g_procfs/cpuinfo")
-            cpu_arch_list=$(awk '/CPU architecture/ {print $3}' "$g_procfs/cpuinfo")
-            cpu_variant_list=$(awk '/CPU variant/   {print $4}' "$g_procfs/cpuinfo")
-            cpu_revision_list=$(awk '/CPU revision/ {print $4}' "$g_procfs/cpuinfo")
+            # keep these single-line (space-separated) so consumers and outputs (JSON, prometheus)
+            # don't end up with embedded newlines; per-core order is preserved for the errata checks
+            cpu_impl_list=$(awk '/CPU implementer/ {print $4}' "$g_procfs/cpuinfo" | tr '\n' ' ')
+            cpu_impl_list=${cpu_impl_list% }
+            cpu_part_list=$(awk '/CPU part/         {print $4}' "$g_procfs/cpuinfo" | tr '\n' ' ')
+            cpu_part_list=${cpu_part_list% }
+            cpu_arch_list=$(awk '/CPU architecture/ {print $3}' "$g_procfs/cpuinfo" | tr '\n' ' ')
+            cpu_arch_list=${cpu_arch_list% }
+            cpu_variant_list=$(awk '/CPU variant/   {print $4}' "$g_procfs/cpuinfo" | tr '\n' ' ')
+            cpu_variant_list=${cpu_variant_list% }
+            cpu_revision_list=$(awk '/CPU revision/ {print $4}' "$g_procfs/cpuinfo" | tr '\n' ' ')
+            cpu_revision_list=${cpu_revision_list% }
         fi
         # Map first-seen implementer to cpu_vendor; note that heterogeneous systems
         # (e.g. DynamIQ with ARM+Kryo cores) would all map to one vendor here, but
@@ -4488,27 +4495,43 @@ check_kernel_cpu_arch_mismatch() {
 # >>>>>> libs/370_hw_vmm.sh <<<<<<
 
 # vim: set ts=4 sw=4 sts=4 et:
-# Check whether the system is running as a Xen paravirtualized guest
-# Returns: 0 if Xen PV, 1 otherwise
-is_xen() {
-    local ret
-    if [ ! -d "$g_procfs/xen" ]; then
-        return 1
+
+# Probe Xen presence and guest type using the most reliable sources available.
+# Prefer /sys/hypervisor when avalable, fallback to dmesg otherwise.
+# Caches results in g_xen (1/0) and g_xen_guest_type (PV|PVH|HVM|'').
+_detect_xen() {
+    [ "${g_xen_cached:-0}" = 1 ] && return
+    g_xen=0
+    g_xen_guest_type=''
+    g_xen_cached=1
+
+    # Most reliable: /sys/hypervisor/type is 'xen' on any Xen domain (dom0
+    # included), and /sys/hypervisor/guest_type reports PV, PVH or HVM.
+    if [ -r /sys/hypervisor/type ] && [ "$(cat /sys/hypervisor/type 2>/dev/null)" = xen ]; then
+        g_xen=1
+        if [ -r /sys/hypervisor/guest_type ]; then
+            g_xen_guest_type=$(cat /sys/hypervisor/guest_type 2>/dev/null)
+        fi
+        return
     fi
 
-    # XXX do we have a better way that relying on dmesg?
+    # Fallback for kernels without /sys/hypervisor: /proc/xen plus a dmesg probe.
+    if [ -d "$g_procfs/xen" ]; then
         dmesg_grep 'Booting paravirtualized kernel on Xen$'
-    ret=$?
-    if [ "$ret" -eq 2 ]; then
-        pr_warn "dmesg truncated, Xen detection will be unreliable. Please reboot and relaunch this script"
-        return 1
-    elif [ "$ret" -eq 0 ]; then
-        return 0
-    else
-        return 1
+        case $? in
+            0) g_xen=1 ;;
+            2) pr_warn "dmesg truncated, Xen detection will be unreliable. Please reboot and relaunch this script" ;;
+        esac
     fi
 }
 
+# Check whether the system is running on Xen (any domain type, dom0 included).
+# Returns: 0 if Xen, 1 otherwise
+is_xen() {
+    _detect_xen
+    [ "$g_xen" = 1 ]
+}
+
 # Check whether the system is a Xen Dom0 (privileged domain)
 # Returns: 0 if Dom0, 1 otherwise
 is_xen_dom0() {
@@ -4523,31 +4546,77 @@ is_xen_dom0() {
     fi
 }
 
-# Check whether the system is a Xen DomU (unprivileged PV guest)
-# Returns: 0 if DomU, 1 otherwise
+# Check whether the system is running as a Xen PV DomU (the only Xen guest type
+# affected by Meltdown, which needs Xen-level mitigation).
+# Returns: 0 if PV DomU, 1 otherwise
 is_xen_domU() {
     local ret
     if ! is_xen; then
         return 1
     fi
 
-    # PVHVM guests also print 'Booting paravirtualized kernel', so we need this check.
+    if is_xen_dom0; then
+        return 1
+    fi
+
+    # When the reliable guest type is known, only PV domains (which aren't
+    # dom0, checked above) are the PV DomU case. PVH and HVM guests are not.
+    if [ -n "$g_xen_guest_type" ]; then
+        [ "$g_xen_guest_type" = PV ] && return 0
+        return 1
+    fi
+
+    # Fallback (no /sys/hypervisor/guest_type): PVHVM guests also print the
+    # 'Booting paravirtualized kernel' line, so exclude them via dmesg.
     dmesg_grep 'Xen HVM callback vector for event delivery is enabled$'
     ret=$?
     if [ "$ret" -eq 0 ]; then
         return 1
     fi
 
-    if ! is_xen_dom0; then
     return 0
-    else
-        return 1
-    fi
 }
 
-# Check whether the system is running as a guest inside a virtual machine.
+# Check whether we're running inside an OS-level container (LXC, Docker,
+# systemd-nspawn, etc.). Containers share the host kernel, so host/hypervisor
+# introspection (e.g. telling a Xen dom0 from a domU) is unreliable from inside
+# one: /proc/xen is exposed but empty, dmesg is the host's, etc. (issue #173)
+# Returns: 0 if in a container, 1 otherwise
+# Sets: g_is_container (1/0), g_container_reason
+is_running_in_container() {
+    local ctype
+    if [ "${g_is_container_cached:-0}" != 1 ]; then
+        g_is_container=0
+        g_container_reason=''
+        # systemd and most runtimes export 'container=' to PID 1's environment
+        if [ -r "$g_procfs/1/environ" ]; then
+            ctype=$(tr '\0' '\n' <"$g_procfs/1/environ" 2>/dev/null | sed -n 's/^container=//p' | head -n1)
+            if [ -n "$ctype" ]; then
+                g_is_container=1
+                g_container_reason="container=$ctype in $g_procfs/1/environ"
+            fi
+        fi
+        # Docker (and some others) drop a marker file at the filesystem root
+        if [ "$g_is_container" = 0 ] && [ -e /.dockerenv ]; then
+            g_is_container=1
+            g_container_reason="/.dockerenv present"
+        fi
+        # cgroup membership often reveals the runtime (lxc, docker, kubepods, ...)
+        if [ "$g_is_container" = 0 ] && [ -r "$g_procfs/1/cgroup" ]; then
+            if grep -qE '(^|[:/])(lxc|docker|kubepods|libpod|containerd|machine\.slice)([/.]|$)' "$g_procfs/1/cgroup" 2>/dev/null; then
+                g_is_container=1
+                g_container_reason="container runtime found in $g_procfs/1/cgroup"
+            fi
+        fi
+        g_is_container_cached=1
+    fi
+    [ "$g_is_container" = 1 ]
+}
+
+# Check whether the system is running as a guest inside a VM.
 # Uses the 'hypervisor' CPUID feature flag exposed in /proc/cpuinfo by KVM,
 # VMware, Hyper-V, VirtualBox, and most other type-1 and type-2 hypervisors.
+# Xen PV/PVH DomUs don't set that flag, so they're detected separately.
 # Returns: 0 if running as a VM guest, 1 otherwise
 # Sets: g_is_guest_vm (1=guest, 0=not a guest), g_is_guest_vm_reason
 is_running_as_guest() {
@@ -4558,6 +4627,13 @@ is_running_as_guest() {
             g_is_guest_vm=1
             g_is_guest_vm_reason="'hypervisor' flag in $g_procfs/cpuinfo"
         fi
+        # Xen PV/PVH DomUs don't expose the 'hypervisor' CPUID flag. Don't
+        # classify a container on a Xen host as a guest here: we can't tell
+        # dom0 from domU from inside a container (handled separately).
+        if [ "$g_is_guest_vm" = 0 ] && is_xen && ! is_xen_dom0 && ! is_running_in_container; then
+            g_is_guest_vm=1
+            g_is_guest_vm_reason="Xen ${g_xen_guest_type:-PV} DomU"
+        fi
         g_is_guest_vm_cached=1
     fi
     [ "$g_is_guest_vm" = 1 ]
@@ -5051,6 +5127,12 @@ check_kernel_info() {
     fi
 }
 
+# Collapse a whitespace-separated list to its unique values, preserving first-seen order.
+# Used to prettify the per-core ARM lists for display (e.g. "0x41 0x41 0x41 0x41" -> "0x41").
+_uniq_list() {
+    echo "$1" | awk '{ for (i = 1; i <= NF; i++) if (!seen[$i]++) printf "%s%s", (n++ ? " " : ""), $i }'
+}
+
 # Display hardware-level CPU mitigation support (microcode features, ARCH_CAPABILITIES, etc.)
 check_cpu() {
     local capabilities ret spec_ctrl_msr codename ucode_str
@@ -5060,13 +5142,13 @@ check_cpu() {
         pr_info "  * Vendor: $cpu_vendor"
         pr_info "  * Model name: $cpu_friendly_name"
         if [ -n "${cpu_impl_list:-}" ]; then
-            pr_info "  * Implementer(s): $cpu_impl_list"
+            pr_info "  * Implementer(s): $(_uniq_list "$cpu_impl_list")"
         fi
         if [ -n "${cpu_part_list:-}" ]; then
-            pr_info "  * Part(s): $cpu_part_list"
+            pr_info "  * Part(s): $(_uniq_list "$cpu_part_list")"
         fi
         if [ -n "${cpu_arch_list:-}" ]; then
-            pr_info "  * Architecture(s): $cpu_arch_list"
+            pr_info "  * Architecture(s): $(_uniq_list "$cpu_arch_list")"
         fi
         if has_runtime; then
             pr_info_nol "  * Running as VM guest: "
@@ -5076,6 +5158,22 @@ check_cpu() {
                 pstatus green NO
             fi
         fi
+        # ARM exposes no userspace-readable CPUID/MSR to query SSBD support directly.
+        # The ARMv8.5 SSBS ("Speculative Store Bypass Safe") hardware bit, when present,
+        # surfaces as the 'ssbs' hwcap in /proc/cpuinfo. We use it *only* as a positive
+        # confirmation of SSB mitigation capability (Variant 4 / CVE-2018-3639): its
+        # absence proves nothing, because the kernel deliberately hides the hwcap on some
+        # cores (e.g. the erratum-3194386 SSBS self-sync workaround), so we must never
+        # infer immunity from a missing 'ssbs'.
+        if has_runtime; then
+            pr_info_nol "  * CPU indicates SSBS (Speculative Store Bypass Safe) capability: "
+            if grep '^Features' "$g_procfs/cpuinfo" | grep -qw ssbs; then
+                cap_ssbd='ARM SSBS (cpuinfo)'
+                pstatus green YES "$cap_ssbd"
+            else
+                pstatus blue UNKNOWN "not exposed (the kernel may hide it; cannot conclude)"
+            fi
+        fi
         return
     fi
 
@@ -6420,6 +6518,12 @@ check_mds_linux() {
                 if echo "$ret_sys_interface_check_fullmsg" | grep -Eq 'SMT (disabled|mitigated)'; then
                     mds_smt_mitigated=1
                     pstatus green YES
+                elif echo "$ret_sys_interface_check_fullmsg" | grep -q 'SMT Host state unknown'; then
+                    # The kernel appends "SMT Host state unknown" when running under
+                    # a hypervisor (X86_FEATURE_HYPERVISOR): the host controls SMT
+                    # scheduling, so it can't be determined from inside the guest (#343).
+                    mds_smt_mitigated=2
+                    pstatus yellow UNKNOWN "running in a VM guest, the hypervisor host controls SMT"
                 else
                     mds_smt_mitigated=0
                     pstatus yellow NO
@@ -6446,6 +6550,9 @@ check_mds_linux() {
                             if [ "$opt_paranoid" != 1 ] || [ "$mds_smt_mitigated" = 1 ]; then
                                 mystatus=OK
                                 mymsg="Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled"
+                            elif [ "$mds_smt_mitigated" = 2 ]; then
+                                mystatus=UNK
+                                mymsg="Your microcode and kernel are both up to date for this mitigation and it's enabled, but SMT (Hyper-Threading) cross-thread protection can't be verified from inside a VM guest: it depends on the hypervisor host's SMT/core-scheduling configuration"
                             else
                                 mystatus=VULN
                                 mymsg="Your microcode and kernel are both up to date for this mitigation, but you must disable SMT (Hyper-Threading) for a complete mitigation"
@@ -6713,6 +6820,12 @@ check_mmio_linux() {
                 if echo "$ret_sys_interface_check_fullmsg" | grep -Eq 'SMT (disabled|mitigated)'; then
                     mmio_smt_mitigated=1
                     pstatus green YES
+                elif echo "$ret_sys_interface_check_fullmsg" | grep -q 'SMT Host state unknown'; then
+                    # The kernel appends "SMT Host state unknown" when running under
+                    # a hypervisor (X86_FEATURE_HYPERVISOR): the host controls SMT
+                    # scheduling, so it can't be determined from inside the guest (#343).
+                    mmio_smt_mitigated=2
+                    pstatus yellow UNKNOWN "running in a VM guest, the hypervisor host controls SMT"
                 else
                     mmio_smt_mitigated=0
                     pstatus yellow NO
@@ -6750,6 +6863,9 @@ check_mmio_linux() {
                             if [ "$opt_paranoid" != 1 ] || [ "$mmio_smt_mitigated" = 1 ]; then
                                 mystatus=OK
                                 mymsg="Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled"
+                            elif [ "$mmio_smt_mitigated" = 2 ]; then
+                                mystatus=UNK
+                                mymsg="Your microcode and kernel are both up to date for this mitigation and it's enabled, but SMT (Hyper-Threading) cross-thread protection can't be verified from inside a VM guest: it depends on the hypervisor host's SMT/core-scheduling configuration"
                             else
                                 mystatus=VULN
                                 mymsg="Your microcode and kernel are both up to date for this mitigation, but you must disable SMT (Hyper-Threading) for a complete mitigation"
@@ -8940,7 +9056,7 @@ check_CVE_2017_5754() {
 }
 
 check_CVE_2017_5754_linux() {
-    local status sys_interface_available msg kpti_support kpti_can_tell kpti_enabled dmesg_grep pti_xen_pv_domU xen_pv_domo xen_pv_domu explain_text
+    local status sys_interface_available msg kpti_support kpti_can_tell kpti_enabled dmesg_grep pti_xen_pv_domU xen_pv_domo xen_pv_domu xen_unknown_container explain_text
     status=UNK
     sys_interface_available=0
     msg=''
@@ -9062,14 +9178,24 @@ check_CVE_2017_5754_linux() {
     # Test if the current host is a Xen PV Dom0 / DomU
     xen_pv_domo=0
     xen_pv_domu=0
+    xen_unknown_container=0
+    if is_xen && ! is_xen_dom0 && is_running_in_container; then
+        # We can see Xen, but we're inside a container so /proc/xen/capabilities
+        # isn't exposed and dmesg is the host's: we can't tell a safe Dom0 from
+        # a vulnerable PV DomU from in here (issue #173).
+        xen_unknown_container=1
+    else
         is_xen_dom0 && xen_pv_domo=1
         is_xen_domU && xen_pv_domu=1
+    fi
 
     if [ "$g_mode" = live ]; then
         # checking whether we're running under Xen PV 64 bits. If yes, we are affected by affected_variant3
         # (unless we are a Dom0)
         pr_info_nol "* Running as a Xen PV DomU: "
-        if [ "$xen_pv_domu" = 1 ]; then
+        if [ "$xen_unknown_container" = 1 ]; then
+            pstatus yellow UNKNOWN "running in a container, can't query Xen from here"
+        elif [ "$xen_pv_domu" = 1 ]; then
             pstatus yellow YES
         else
             pstatus blue NO
@@ -9082,7 +9208,10 @@ check_CVE_2017_5754_linux() {
     elif [ -z "$msg" ]; then
         # if msg is empty, sysfs check didn't fill it, rely on our own test
         if [ "$g_mode" = live ]; then
-            if [ "$kpti_enabled" = 1 ]; then
+            if [ "$xen_unknown_container" = 1 ]; then
+                pvulnstatus "$cve" UNK "running inside a container on a Xen host, can't determine if the underlying domain is a vulnerable PV DomU"
+                explain "This system looks like a container ($g_container_reason) running on a Xen host. Whether the underlying domain is a safe Dom0 or a vulnerable PV DomU can't be reliably determined from inside a container (/proc/xen is exposed but empty, and dmesg belongs to the host). Please re-run this script directly on the host, outside the container, to get an accurate result."
+            elif [ "$kpti_enabled" = 1 ]; then
                 pvulnstatus "$cve" OK "PTI mitigates the vulnerability"
             elif [ "$xen_pv_domo" = 1 ]; then
                 pvulnstatus "$cve" OK "Xen Dom0s are safe and do not require PTI"
@@ -10115,6 +10244,11 @@ check_CVE_2019_11135_linux() {
                 pvulnstatus "$cve" VULN "TSX must be disabled for full mitigation"
             elif echo "$ret_sys_interface_check_fullmsg" | grep -qF 'SMT vulnerable'; then
                 pvulnstatus "$cve" VULN "SMT (HyperThreading) must be disabled for full mitigation"
+            elif echo "$ret_sys_interface_check_fullmsg" | grep -qF 'SMT Host state unknown'; then
+                # The kernel appends "SMT Host state unknown" when running under a
+                # hypervisor (X86_FEATURE_HYPERVISOR): the host controls SMT
+                # scheduling, so it can't be determined from inside the guest (#343).
+                pvulnstatus "$cve" UNK "TAA is mitigated and TSX is disabled, but SMT (Hyper-Threading) cross-thread protection can't be verified from inside a VM guest: it depends on the hypervisor host's SMT/core-scheduling configuration"
             else
                 pvulnstatus "$cve" "$status" "$msg"
             fi
@@ -11540,6 +11674,15 @@ check_CVE_2023_20593_linux() {
             fi
         fi
         if [ "$zenbleed_print_vuln" = 1 ]; then
+            if [ "$g_mode" = live ] && is_running_as_guest; then
+                # Both Zenbleed mitigations are applied at the host level: an
+                # up-to-date microcode, or the host kernel setting FP_BACKUP_FIX
+                # in DE_CFG. From inside a guest we can't read that MSR and can't
+                # trust the microcode version the hypervisor presents, so we can't
+                # confirm or deny the mitigation -- don't cry VULN (#488).
+                pvulnstatus "$cve" UNK "Zenbleed mitigation can't be verified from inside a VM guest ($g_is_guest_vm_reason): it may be applied by the hypervisor host, but that isn't observable from here"
+                explain "Zenbleed is mitigated either by an up-to-date CPU microcode or by the host kernel setting the FP_BACKUP_FIX bit (DE_CFG MSR 0xc0011029 bit 9). Both are host-level: a guest can neither read that MSR nor trust the microcode version the hypervisor presents (see the VM note in the hardware section above). Re-run this script on the hypervisor host to get an accurate result."
+            else
                 pvulnstatus "$cve" VULN "Your kernel is too old to mitigate Zenbleed and your CPU microcode doesn't mitigate it either"
                 explain "Your CPU vendor may have a new microcode for your CPU model that mitigates this issue (refer to the hardware section above).\n " \
                     "Otherwise, the Linux kernel is able to mitigate this issue regardless of the microcode version you have, but in this case\n " \
@@ -11548,6 +11691,7 @@ check_CVE_2023_20593_linux() {
                     "To manually mitigate the issue right now, you may use the following command: \`wrmsr -a 0xc0011029 \$((\$(rdmsr -c 0xc0011029) | (1<<9)))\`,\n " \
                     "however note that this manual mitigation will only be active until the next reboot."
             fi
+        fi
         unset zenbleed_print_vuln
     else
         pvulnstatus "$cve" "$status" "$msg"
@@ -13120,7 +13264,7 @@ exit 0                          # ok
 # with X being either I for Intel, or A for AMD
 # When the date is unknown it defaults to 20000101
 
-# %%% MCEDB v349+i20260512+1cce
+# %%% MCEDB v350+i20260512+1cce
 # I,0x00000611,0xFF,0x00000B27,19961218
 # I,0x00000612,0xFF,0x000000C6,19961210
 # I,0x00000616,0xFF,0x000000C6,19961210
@@ -13539,6 +13683,7 @@ exit 0                          # ok
 # I,0x000A06D0,0xFF,0x10000680,20240818
 # I,0x000A06D1,0x20,0x0A000142,20260129
 # I,0x000A06D1,0x95,0x01000423,20260129
+# I,0x000A06E0,0xFF,0x80000953,20240902
 # I,0x000A06E1,0x97,0x01000307,20260226
 # I,0x000A06F0,0xFF,0x80000360,20240130
 # I,0x000A06F3,0x01,0x030003A3,20260130
@@ -13568,8 +13713,10 @@ exit 0                          # ok
 # I,0x000C06C3,0x90,0x0000011B,20260324
 # I,0x000C06F1,0x87,0x210002E0,20251217
 # I,0x000C06F2,0x87,0x210002E0,20251217
-# I,0x000D0670,0xFF,0x00000003,20250825
-# I,0x000D06D0,0xFF,0x00000340,20250807
+# I,0x000D0650,0xFF,0x00000008,20260208
+# I,0x000D0651,0xFF,0x00000008,20260208
+# I,0x000D0670,0xFF,0x00000137,20260218
+# I,0x000D06D0,0xFF,0x80000370,20250917
 # I,0x00FF0671,0xFF,0x0000010E,20220907
 # I,0x00FF0672,0xFF,0x0000000D,20210816
 # I,0x00FF0675,0xFF,0x0000000D,20210816
@@ -13666,7 +13813,7 @@ exit 0                          # ok
 # A,0x00880F40,0xFF,0x08804005,20210312
 # A,0x00890F00,0xFF,0x08900007,20200921
 # A,0x00890F01,0xFF,0x08900103,20201105
-# A,0x00890F02,0xFF,0x08900203,20230915
+# A,0x00890F02,0xFF,0x08900208,20241219
 # A,0x00890F10,0xFF,0x08901003,20230919
 # A,0x008A0F00,0xFF,0x08A0000B,20241125
 # A,0x00A00F00,0xFF,0x0A000033,20200413
@@ -13711,11 +13858,11 @@ exit 0                          # ok
 # A,0x00B00F00,0xFF,0x0B00004D,20240318
 # A,0x00B00F10,0xFF,0x0B001016,20240318
 # A,0x00B00F20,0xFF,0x0B002032,20241003
-# A,0x00B00F21,0xFF,0x0B002161,20251105
+# A,0x00B00F21,0xFF,0x0B002162,20251105
 # A,0x00B00F80,0xFF,0x0B008011,20241211
 # A,0x00B00F81,0xFF,0x0B008121,20251020
 # A,0x00B10F00,0xFF,0x0B10000F,20240320
-# A,0x00B10F10,0xFF,0x0B101058,20251105
+# A,0x00B10F10,0xFF,0x0B101059,20251105
 # A,0x00B20F40,0xFF,0x0B204037,20251019
 # A,0x00B40F00,0xFF,0x0B400034,20240318
 # A,0x00B40F40,0xFF,0x0B404035,20251020