release: sync v26.36.0913490 from source-build

built from source-build commit b4d3328cc1
 dated 2026-09-13 11:47:12 +0000

.github/workflows/autoupdate.yml

@@ -7,30 +7,117 @@ on:
 
 permissions:
   pull-requests: write
+  contents: write
 
 jobs:
   autoupdate:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v6
+        with:
+          ref: source
       - name: Install prerequisites
-        run: sudo apt-get update && sudo apt-get install -y --no-install-recommends iucode-tool sqlite3 unzip
+        run: sudo apt-get update && sudo apt-get install -y --no-install-recommends iucode-tool sqlite3 unzip shfmt python3
       - name: Update microcode versions
-        run: ./spectre-meltdown-checker.sh --update-builtin-fwdb
+        run: ./scripts/update_mcedb.sh
+      - name: Update Intel models
+        run: ./scripts/update_intel_models.sh
+      - name: Update Intel affected processors
+        run: |
+          git clone https://github.com/intel/Intel-affected-processor-list.git \
+            "$RUNNER_TEMP/Intel-affected-processor-list"
+          python3 scripts/intel-affected-processor-list/build_inteldb.py \
+            "$RUNNER_TEMP/Intel-affected-processor-list" src/db/100_inteldb.sh \
+            --base-db scripts/intel-affected-processor-list/historical_records.db
       - name: Check git diff
         id: diff
         run: |
-          echo change="$(git diff spectre-meltdown-checker.sh | awk '/MCEDB/ { if(V) { print V" to "$4; exit } else { V=$4 } }')" >> "$GITHUB_OUTPUT"
-          echo nbdiff="$(git diff spectre-meltdown-checker.sh | grep -cE -- '^\+# [AI],')" >> "$GITHUB_OUTPUT"
+          if git diff --quiet -- src/db/200_mcedb.sh src/libs/003_intel_models.sh src/db/100_inteldb.sh; then
+            echo "changed=false" >> "$GITHUB_OUTPUT"
+          else
+            echo "changed=true" >> "$GITHUB_OUTPUT"
+          fi
+          python3 - <<'PY'
+          import os
+          import re
+          import subprocess
+          from pathlib import Path
+
+          def previous(path):
+              return subprocess.check_output(['git', 'show', f'HEAD:{path}'], text=True)
+
+          def records(text, kind):
+              result = {}
+              for line in text.splitlines():
+                  if kind == 'microcode' and re.match(r'^# [AI],', line):
+                      fields = line[2:].split(',')
+                      result[tuple(fields[:3])] = tuple(fields[3:])
+                  elif kind == 'models':
+                      match = re.match(r'\s*readonly (INTEL_\w+)=(.*)', line)
+                      if match:
+                          result[match[1]] = match[2]
+                  elif kind == 'processors' and line.startswith('# 0x'):
+                      fields = line[2:].rstrip(',').split(',')
+                      qualifier = fields[1] if fields[1].startswith('H=') else ''
+                      result[(fields[0], qualifier)] = tuple(fields[2:] if qualifier else fields[1:])
+              return result
+
+          outputs = {}
+          for kind, path in (
+              ('microcode', 'src/db/200_mcedb.sh'),
+              ('models', 'src/libs/003_intel_models.sh'),
+              ('processors', 'src/db/100_inteldb.sh'),
+          ):
+              old_text = previous(path)
+              new_text = Path(path).read_text(encoding='utf-8')
+              old = records(old_text, kind)
+              new = records(new_text, kind)
+              added = len(new.keys() - old.keys())
+              removed = len(old.keys() - new.keys())
+              updated = sum(old[key] != new[key] for key in old.keys() & new.keys())
+              outputs[kind] = f'{added} added, {updated} updated, {removed} removed ({len(new)} total)'
+              if kind == 'microcode':
+                  def version(text):
+                      match = re.search(r'^# %%% MCEDB (\S+)', text, re.MULTILINE)
+                      if not match:
+                          raise ValueError('Missing MCEDB version marker')
+                      return match[1]
+                  before, after = version(old_text), version(new_text)
+                  outputs['mcedb'] = f'{before} -> {after}' if before != after else f'{after} (unchanged)'
+                  outputs['microcode_changes'] = added + updated + removed
+          outputs['intel_revision'] = subprocess.check_output(
+              ['git', '-C', os.path.join(os.environ['RUNNER_TEMP'], 'Intel-affected-processor-list'),
+               'rev-parse', 'HEAD'], text=True,
+          ).strip()
+          with open(os.environ['GITHUB_OUTPUT'], 'a', encoding='utf-8') as stream:
+              for key, value in outputs.items():
+                  print(f'{key}={value}', file=stream)
+          PY
           git diff
           cat "$GITHUB_OUTPUT"
       - name: Create Pull Request if needed
-        if: steps.diff.outputs.nbdiff != '0'
+        if: steps.diff.outputs.changed == 'true'
         uses: peter-evans/create-pull-request@v7
         with:
+          base: source
           branch: autoupdate-fwdb
-          commit-message: "update: fwdb from ${{ steps.diff.outputs.change }}, ${{ steps.diff.outputs.nbdiff }} microcode changes"
-          title: "[Auto] Update fwdb from ${{ steps.diff.outputs.change }}"
+          add-paths: |
+            src/db/200_mcedb.sh
+            src/libs/003_intel_models.sh
+            src/db/100_inteldb.sh
+          commit-message: |
+            update: CPU databases, ${{ steps.diff.outputs.microcode_changes }} microcode changes
+
+            MCEDB: ${{ steps.diff.outputs.mcedb }}
+            Microcode records: ${{ steps.diff.outputs.microcode }}
+            Intel models: ${{ steps.diff.outputs.models }}
+            Intel affected-processor profiles: ${{ steps.diff.outputs.processors }}
+            Intel CSV revision: ${{ steps.diff.outputs.intel_revision }}
+          title: "[Auto] Update CPU databases: MCEDB ${{ steps.diff.outputs.mcedb }}, ${{ steps.diff.outputs.microcode_changes }} microcode changes"
           body: |
-            Automated PR to update fwdb from ${{ steps.diff.outputs.change }}
-            Detected ${{ steps.diff.outputs.nbdiff }} microcode changes
+            Automated PR to refresh the CPU/microcode databases:
+
+            - **MCEDB version:** ${{ steps.diff.outputs.mcedb }}
+            - **Microcode records:** ${{ steps.diff.outputs.microcode }}
+            - **Intel CPU models:** ${{ steps.diff.outputs.models }}
+            - **Intel affected-processor profiles:** ${{ steps.diff.outputs.processors }}

.github/workflows/expected_cve_count

@@ -1 +1 @@
-31
+32

.github/workflows/release.yml

@@ -0,0 +1,181 @@
+name: release
+
+# Manual, path-scoped release helper for master.
+#
+# `master` is BOTH the distribution branch (users download the script here)
+# AND the default branch that hosts the scheduled CI workflows
+# (autoupdate / stale / vuln-watch). `source-build` is a build-OUTPUT branch.
+#
+# We therefore never merge source-build into master: that would drag source-build's
+# whole tree, including the *absence* of the master-only workflows.
+# Instead we copy only the assembled artifact files across, and cut GitHub
+# releases from master directly.
+#
+# Two independent manual actions to run against the `master` branch:
+#
+#   1. sync-from-source-build : open a PR against master carrying the assembled
+#                               files (everything on source-build EXCEPT
+#                               .github/). Nothing lands on master until the PR
+#                               is reviewed and merged.
+#   2. draft-github-release   : create a DRAFT GitHub release from the script
+#                               currently on master, with an auto-drafted
+#                               changelog.
+
+on:
+  workflow_dispatch:
+    inputs:
+      action:
+        description: What to do
+        type: choice
+        required: true
+        default: sync-from-source-build
+        options:
+          - sync-from-source-build
+          - draft-github-release
+
+permissions:
+  contents: write
+  pull-requests: write
+
+concurrency:
+  group: release-master
+  cancel-in-progress: false
+
+jobs:
+  # ---------------------------------------------------------------------------
+  # 1. Copy assembled files from source-build onto master (no .github/),
+  #    as a pull request.
+  # ---------------------------------------------------------------------------
+  sync-from-source-build:
+    if: inputs.action == 'sync-from-source-build'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          ref: master
+          fetch-depth: 0
+          persist-credentials: true
+
+      - name: sync assembled files from source-build
+        id: sync
+        run: |
+          set -eu
+          git fetch --no-tags origin source-build
+
+          # Every top-level entry on source-build EXCEPT .github/ (master keeps
+          # its own CI). Computed dynamically so any new top-level artifact is
+          # picked up automatically.
+          readarray -t paths < <(git ls-tree --name-only origin/source-build | grep -vxF '.github')
+          echo "Syncing: ${paths[*]}"
+
+          # Mirror source-build exactly for those paths, removing first so that
+          # deletions/renames inside doc/ etc. propagate too.
+          for p in "${paths[@]}"; do rm -rf -- "$p"; done
+          git checkout origin/source-build -- "${paths[@]}"
+          git add --all -- "${paths[@]}"
+
+          if git diff --cached --quiet; then
+            echo "master already up to date with source-build; nothing to sync."
+            echo "changed=false" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+
+          {
+            echo "changed=true"
+            echo "version=$(grep -m1 "^VERSION=" spectre-meltdown-checker.sh | cut -d"'" -f2)"
+            echo "sb=$(git rev-parse origin/source-build)"
+            echo "sbdate=$(git log -1 --format=%ai origin/source-build)"
+          } >> "$GITHUB_OUTPUT"
+
+      # Note: the repo must have "Allow GitHub Actions to create and approve
+      # pull requests" enabled for this to work.
+      - name: open the sync pull request
+        if: steps.sync.outputs.changed == 'true'
+        uses: peter-evans/create-pull-request@v7
+        with:
+          base: master
+          branch: release/sync-from-source-build
+          delete-branch: true
+          committer: "github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>"
+          author: "github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>"
+          title: "release: sync v${{ steps.sync.outputs.version }} from source-build"
+          commit-message: |
+            release: sync v${{ steps.sync.outputs.version }} from source-build
+
+             built from source-build commit ${{ steps.sync.outputs.sb }}
+             dated ${{ steps.sync.outputs.sbdate }}
+          body: |
+            Assembled files copied from `source-build` onto `master` (everything
+            except `.github/`, which stays master-only).
+
+            - version: `${{ steps.sync.outputs.version }}`
+            - built from source-build commit: ${{ steps.sync.outputs.sb }}
+            - dated: ${{ steps.sync.outputs.sbdate }}
+
+            Once merged, run this workflow again with the `draft-github-release`
+            action to cut the release, if required.
+
+  # ---------------------------------------------------------------------------
+  # 2. Draft a GitHub release from the script currently on master.
+  # ---------------------------------------------------------------------------
+  draft-github-release:
+    if: inputs.action == 'draft-github-release'
+    runs-on: ubuntu-latest
+    env:
+      GH_TOKEN: ${{ github.token }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          ref: master
+          fetch-depth: 0
+          persist-credentials: true
+
+      - name: draft a release from the current master script
+        run: |
+          set -eu
+          ver=$(grep -m1 "^VERSION=" spectre-meltdown-checker.sh | cut -d"'" -f2)
+          tag="v${ver}"
+
+          if gh release view "$tag" >/dev/null 2>&1; then
+            echo "A release for $tag already exists; refusing to recreate." >&2
+            echo "Delete it first if needed." >&2
+            exit 1
+          fi
+
+          # Draft the changelog from the source-build commits assembled since the
+          # previous published release. We locate the source-build commit whose
+          # built VERSION equals the last release tag, then list what came after.
+          git fetch --no-tags origin source-build
+          last_tag=$(gh release list --exclude-drafts --limit 1 --json tagName --jq '.[0].tagName // empty')
+          old_ver="${last_tag#v}"
+
+          base=""
+          if [ -n "$old_ver" ]; then
+            while read -r h; do
+              v=$(git show "$h:spectre-meltdown-checker.sh" 2>/dev/null | grep -m1 "^VERSION=" | cut -d"'" -f2 || true)
+              if [ "$v" = "$old_ver" ]; then base="$h"; break; fi
+            done < <(git rev-list --max-count=500 origin/source-build)
+          fi
+
+          {
+            echo "## ${tag}"
+            echo
+            if [ -n "$base" ]; then
+              git log --no-merges --format='- %s' "${base}..origin/source-build"
+            else
+              echo "_Could not determine the previous release point automatically — please fill in the changelog. Last 30 assembled commits below as a starting point:_"
+              echo
+              git log --no-merges --format='- %s' --max-count=30 origin/source-build
+            fi
+          } > notes.md
+
+          echo "----- draft notes -----"; cat notes.md; echo "-----------------------"
+
+          gh release create "$tag" \
+            --draft \
+            --target "$GITHUB_SHA" \
+            --title "$tag" \
+            --notes-file notes.md \
+            spectre-meltdown-checker.sh
+
+          echo "Draft release $tag created."

.github/workflows/stale.yml

@@ -8,7 +8,7 @@ on:
       action:
         description: "dry-run"
         required: true
-        default: "dryrun"
+        default: "apply"
         type: choice
         options:
           - dryrun
@@ -30,4 +30,7 @@ jobs:
           days-before-close: 7
           stale-issue-label: stale
           remove-stale-when-updated: true
+          close-issue-reason: completed
+          stale-issue-message: "If there are no further comments or activity on this issue, it'll be closed automatically in 7 days."
+          close-issue-message: "Automatically closing this issue due to inactivity, don't hesitate to open a new issue if needed."
           debug-only: ${{ case(inputs.action == 'dryrun', true, false) }}

.github/workflows/vuln-watch.yml

@@ -0,0 +1,190 @@
+name: Online search for vulns
+
+on:
+  schedule:
+    - cron: '42 8 * * *'
+  workflow_dispatch:
+    inputs:
+      model:
+        description: 'Claude model to use (cron runs default to Sonnet)'
+        required: false
+        type: choice
+        default: claude-sonnet-4-6
+        options:
+          - claude-sonnet-4-6
+          - claude-opus-4-7
+          - claude-haiku-4-5-20251001
+      window_hours:
+        description: 'Lookback window in hours (cron runs use 25)'
+        required: false
+        type: string
+        default: '25'
+      reconsider_age_days:
+        description: 'Only reconsider backlog entries last reviewed ≥ N days ago (0 = all, default 7)'
+        required: false
+        type: string
+        default: '7'
+
+permissions:
+  contents: read
+  actions: read           # needed to list/download previous run artifacts
+  id-token: write         # needed by claude-code-action for OIDC auth
+
+concurrency:
+  group: vuln-watch
+  cancel-in-progress: true
+
+jobs:
+  watch:
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+
+    steps:
+      # The scripts driving this workflow live on the `vuln-watch` branch so
+      # they don't clutter master (which is what ships to production). The
+      # workflow file itself MUST stay on the default branch, as GitHub only
+      # honors `schedule:` triggers on the default branch.
+      - name: Checkout vuln-watch branch (scripts + prompt)
+        uses: actions/checkout@v6
+        with:
+          ref: vuln-watch
+          fetch-depth: 1
+          persist-credentials: false
+
+      - name: Set up Python
+        uses: actions/setup-python@v6
+        with:
+          python-version: '3.12'
+
+      - name: Install Python dependencies
+        run: python -m pip install --quiet feedparser
+
+      # ---- Load previous state ---------------------------------------------
+      # Find the most recent successful run of THIS workflow (other than the
+      # current one) and pull its `vuln-watch-state` artifact. On the very
+      # first run there will be none — that's fine, we start empty.
+      - name: Find previous successful run id
+        id: prev
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          set -e
+          run_id=$(gh run list \
+            --workflow="${{ github.workflow }}" \
+            --status=success \
+            --limit 1 \
+            --json databaseId \
+            --jq '.[0].databaseId // empty')
+          echo "run_id=${run_id}" >> "$GITHUB_OUTPUT"
+          if [ -n "$run_id" ]; then
+            echo "Found previous successful run: $run_id"
+          else
+            echo "No previous successful run — starting from empty state."
+          fi
+
+      - name: Download previous state artifact
+        if: steps.prev.outputs.run_id != ''
+        uses: actions/download-artifact@v8
+        continue-on-error: true   # tolerate retention expiry
+        with:
+          name: vuln-watch-state
+          path: state/
+          run-id: ${{ steps.prev.outputs.run_id }}
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+
+      # ---- Fetch + diff (token-free; runs every time) ---------------------
+      # Performs conditional GETs (ETag / If-Modified-Since) against every
+      # source, parses RSS/Atom/HTML, dedups against state.seen + state.aliases,
+      # applies the time-window filter, and emits new_items.json.
+      # Updates state.sources (HTTP cache metadata + per-source high-water
+      # marks) in place so the cache survives even when Claude doesn't run.
+      - name: Fetch + diff all sources
+        id: diff
+        env:
+          SCAN_DATE: ${{ github.run_started_at }}
+          # Cron runs have no `inputs` context, so the fallback kicks in.
+          WINDOW_HOURS:         ${{ inputs.window_hours || '25' }}
+          RECONSIDER_AGE_DAYS:  ${{ inputs.reconsider_age_days || '7' }}
+        run: python -m scripts.vuln_watch.fetch_and_diff
+
+      # ---- Fetch checker code so Claude can grep it for coverage ---------
+      # The orphan vuln-watch branch has none of the actual checker code,
+      # so we pull the `test` branch (the dev branch where coded-but-
+      # unreleased CVE checks live) into ./checker/. The prompt tells
+      # Claude this is the canonical source of truth for "is CVE-X already
+      # implemented?". Only fetched on days with something to classify.
+      - name: Checkout checker code (test branch) for coverage grep
+        if: steps.diff.outputs.new_count != '0' || steps.diff.outputs.reconsider_count != '0'
+        uses: actions/checkout@v6
+        with:
+          ref: test
+          path: checker
+          fetch-depth: 1
+          persist-credentials: false
+
+      # ---- Classify new items with Claude (skipped when nothing is new) ---
+      # Model selection: a manual workflow_dispatch run picks from a dropdown
+      # (defaulting to Sonnet). Scheduled cron runs have no `inputs` context,
+      # so the `|| 'claude-sonnet-4-6'` fallback kicks in — cron always uses
+      # Sonnet to keep the daily cost floor low.
+      - name: Run classifier with Claude
+        id: classify
+        if: steps.diff.outputs.new_count != '0' || steps.diff.outputs.reconsider_count != '0'
+        uses: anthropics/claude-code-action@v1
+        env:
+          SCAN_DATE: ${{ github.run_started_at }}
+        with:
+          prompt: |
+            Read the full task instructions from scripts/daily_vuln_watch_prompt.md
+            and execute them end-to-end. Your input is new_items.json (already
+            deduped, windowed, and pre-filtered — do NOT re-fetch sources).
+            Write the three watch_${TODAY}_*.md files and classifications.json.
+            Use $SCAN_DATE as the canonical timestamp.
+          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+          # model + tool allowlist pass through claude_args (v1 dropped the
+          # dedicated `model:` and `allowed_tools:` inputs). Job-level
+          # `timeout-minutes: 20` above bounds total runtime.
+          claude_args: |
+            --model ${{ inputs.model || 'claude-sonnet-4-6' }}
+            --allowedTools "Read,Write,Edit,Bash,Grep,Glob,WebFetch"
+
+      - name: Upload Claude execution log
+        if: ${{ always() && steps.classify.outputs.execution_file != '' }}
+        uses: actions/upload-artifact@v7
+        with:
+          name: claude-execution-log-${{ github.run_id }}
+          path: ${{ steps.classify.outputs.execution_file }}
+          retention-days: 30
+          if-no-files-found: warn
+
+      # ---- Merge classifications back into state --------------------------
+      # Also writes stub watch_*.md files if the classify step was skipped, so
+      # the report artifact is consistent across runs.
+      - name: Merge classifications into state
+        if: always()
+        env:
+          SCAN_DATE: ${{ github.run_started_at }}
+        run: python -m scripts.vuln_watch.merge_state
+
+      - name: Upload new state artifact
+        if: always()
+        uses: actions/upload-artifact@v7
+        with:
+          name: vuln-watch-state
+          path: state/seen.json
+          retention-days: 90
+          if-no-files-found: error
+
+      - name: Upload daily report
+        if: always()
+        uses: actions/upload-artifact@v7
+        with:
+          name: vuln-watch-report-${{ github.run_id }}
+          path: |
+            watch_*.md
+            current_toimplement.md
+            current_tocheck.md
+            new_items.json
+            classifications.json
+          retention-days: 90
+          if-no-files-found: warn

README.md

@@ -38,6 +38,15 @@ CVE | Name | Aliases
 [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
+[CVE-2025-54505](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-54505) | AMD Zen1 Floating-Point Divider Stale Data Leak | FPDSS
+
+The following entries are ARM64 silicon errata that the kernel actively works around. They have no assigned CVE; they are tracked only by ARM's erratum numbers. Select them with `--errata <number>` or the associated `--variant` mnemonic.
+
+ID | Name | Affected cores
+-- | ---- | --------------
+CVE-0001-0001 | Speculative AT TLB corruption (errata 1165522, 1319367, 1319537, 1530923) | Cortex-A55/A57/A72/A76
+CVE-0001-0002 | Speculative unprivileged load (errata 2966298, 3117295) | Cortex-A510/A520
+CVE-0001-0003 | MSR SSBS not self-synchronizing (erratum 3194386 + siblings) | Cortex-A76/A77/A78/A78C/A710/A715/A720/A720AE/A725, X1/X1C/X2/X3/X4/X925, Neoverse-N1/N2/N3/V1/V2/V3/V3AE
 
 ## Am I at risk?
 
@@ -77,6 +86,7 @@ CVE-2024-36350 (TSA-SQ) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel
 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
+CVE-2025-54505 (FPDSS) | 💥 | 💥 | 💥 | 💥 | Kernel update
 
 > 💥 Data can be leaked across this boundary.
 
@@ -207,6 +217,10 @@ After a guest VM exits to the host, stale branch predictions from the guest can
 
 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.
 
+**CVE-2025-54505 — AMD Zen1 Floating-Point Divider Stale Data Leak (FPDSS)**
+
+On AMD Zen1 and Zen+ processors (EPYC 7001, EPYC Embedded 3000, Athlon 3000 with Radeon, Ryzen 3000 with Radeon, Ryzen PRO 3000 with Radeon Vega), the hardware floating-point divider can retain partial quotient data from previous operations. Under certain circumstances, those results can be leaked to another thread sharing the same divider, crossing any privilege boundary. This was assigned CVE-2025-54505 and published by AMD as AMD-SB-7053 on 2026-04-17. Mitigation requires a kernel update (mainline commit e55d98e77561, "x86/CPU: Fix FPDSS on Zen1", Linux 7.1) that sets bit 9 (ZEN1_DENORM_FIX_BIT) of MSR 0xc0011028 (MSR_AMD64_FP_CFG) unconditionally on every Zen1 CPU at boot, disabling the hardware optimization responsible for the leak. No microcode update is required: the chicken bit is present in Zen1 silicon from the factory and is independent of microcode revision. Performance impact is limited to a small reduction in floating-point divide throughput, which is why AMD does not enable the bit by default in hardware.
+
 </details>
 
 ## Unsupported CVEs
@@ -266,23 +280,23 @@ In **Hardware-only** mode, the script only reports CPU information and per-CVE h
 
 - Get the latest version of the script using `curl` *or* `wget`
 
-```bash
-curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
-wget https://meltdown.ovh -O spectre-meltdown-checker.sh
-```
+    ```bash
+    curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
+    wget https://meltdown.ovh -O spectre-meltdown-checker.sh
+    ```
 
 - Inspect the script. You never blindly run scripts you downloaded from the Internet, do you?
 
-```bash
-vim spectre-meltdown-checker.sh
-```
+    ```bash
+    vim spectre-meltdown-checker.sh
+    ```
 
 - When you're ready, run the script as root
 
-```bash
-chmod +x spectre-meltdown-checker.sh
-sudo ./spectre-meltdown-checker.sh
-```
+    ```bash
+    chmod +x spectre-meltdown-checker.sh
+    sudo ./spectre-meltdown-checker.sh
+    ```
 
 ### Using a docker container
 

doc/UNSUPPORTED_CVE_LIST.md

@@ -124,6 +124,17 @@ A branch predictor initialization issue specific to Intel's Lion Cove microarchi
 
 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-3665 — Lazy FP State Restore (LazyFP)
+
+- **Advisory:** [INTEL-SA-00145](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/lazy-fp-state-restore.html)
+- **Research paper:** [LazyFP: Leaking FPU Register State using Microarchitectural Side-Channels (Stecklina & Prescher, 2018)](https://arxiv.org/abs/1806.07480)
+- **Affected CPUs:** Intel Core family (Sandy Bridge through Kaby Lake) when lazy FPU switching is in use
+- **CVSS:** 4.3 (Medium)
+
+Intel CPUs using lazy FPU state switching may speculatively expose another process's FPU/SSE/AVX register contents (including AES round keys and other cryptographic material) across context switches. The `#NM` (device-not-available) exception normally used to trigger lazy restore is delivered late enough that dependent instructions can transiently execute against the stale FPU state before the fault squashes them.
+
+**Why out of scope:** The Linux mitigation is to use eager FPU save/restore, which was already the default on Intel CPUs with XSAVEOPT well before disclosure, and was then hard-enforced upstream by the removal of all lazy FPU code in Linux 4.14 (Andy Lutomirski's "x86/fpu: Hard-disable lazy FPU mode" cleanup). There is no `/sys/devices/system/cpu/vulnerabilities/` entry, no CPUID flag, no MSR, and no kernel config option that reflects this mitigation — detection on a running kernel would require hardcoding kernel version ranges, which is against this tool's design principles (same rationale as CVE-2019-15902). In practice, any supported kernel today is eager-FPU-only, and CPUs advertising XSAVEOPT/XSAVES cannot enter the vulnerable lazy-switching mode regardless of kernel configuration.
+
 ## CVE-2018-9056 — BranchScope
 
 - **Issue:** [#169](https://github.com/speed47/spectre-meltdown-checker/issues/169)
@@ -177,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)
@@ -296,3 +319,35 @@ A weakness in AMD's microcode signature verification (AES-CMAC hash) allows load
 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.
+
+## 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)
+- **Intel whitepaper:** [Mitigations for Jump Conditional Code Erratum](https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf)
+- **Affected CPUs:** Intel 6th through 10th generation Core and Xeon processors (Skylake through Cascade Lake)
+
+A microarchitectural correctness erratum where a conditional jump instruction that straddles or ends at a 64-byte instruction fetch boundary can corrupt the branch predictor state, potentially causing incorrect execution. Intel addressed this in a November 2019 microcode update. Compilers and assemblers (GCC, LLVM, binutils) also introduced alignment options (`-mbranch-alignment`, `-x86-branches-within-32B-boundaries`) to pad jump instructions away from boundary conditions, preserving performance on CPUs with updated microcode.
+
+**Why out of scope:** The JCC erratum is a microarchitectural correctness bug, not a transient or speculative execution side-channel vulnerability. No CVE was ever assigned. Red Hat noted that privilege escalation "has not been ruled out" but made no definitive security finding, and no exploit has been demonstrated. There is no Linux sysfs entry, no CPUID bit, and no MSR flag exposing the mitigation status. The microcode fix introduces no detectable hardware indicator, so checking for it would require maintaining a per-CPU-stepping minimum microcode version table (the design principle 3 exception) — costly to maintain without a CVE anchor or confirmed exploitability to justify the ongoing work. The kernel compiler mitigation is a build-time-only change (instruction alignment) with no observable runtime state.

doc/batch_json.md

@@ -102,7 +102,9 @@ boundaries by a malicious guest.  Prioritise remediation where
 
 ### `cpu`
 
-CPU hardware identification.  `null` when `--no-hw` is active.
+CPU hardware identification.  `null` when `--no-hw` is active, or when
+`--arch-prefix` is set (host CPU info is then suppressed to avoid mixing
+with a different-arch target kernel).
 
 The object uses `arch` as a discriminator: `"x86"` for Intel/AMD/Hygon CPUs,
 `"arm"` for ARM/Cavium/Phytium.  Arch-specific fields live under a matching
@@ -140,7 +142,7 @@ fields from the other architecture.
 
 #### `cpu.x86.capabilities`
 
-Each capability is a **tri-state**: `true` (present), `false` (absent), or
+Every capability is a **tri-state**: `true` (present), `false` (absent), or
 `null` (not applicable or could not be read, e.g. when not root or on AMD for
 Intel-specific features).
 
@@ -238,7 +240,7 @@ with an unknown CVE ID).
 | `status` | string | `"OK"` / `"VULN"` / `"UNK"` | Check outcome (see below) |
 | `vulnerable` | boolean \| null | `false` / `true` / `null` | `false`=OK, `true`=VULN, `null`=UNK |
 | `info` | string | | Human-readable description of the specific mitigation state or reason |
-| `sysfs_status` | string \| null | `"OK"` / `"VULN"` / `"UNK"` / null | Status as reported by the kernel via `/sys/devices/system/cpu/vulnerabilities/`; null if sysfs was not consulted for this CVE |
+| `sysfs_status` | string \| null | `"OK"` / `"VULN"` / `"UNK"` / null | Status as reported by the kernel via `/sys/devices/system/cpu/vulnerabilities/`; null if sysfs was not consulted for this CVE, or if the CVE's check read sysfs in silent/quiet mode (raw message is still captured in `sysfs_message`) |
 | `sysfs_message` | string \| null | | Raw text from the sysfs file (e.g. `"Mitigation: PTI"`); null if sysfs was not consulted |
 
 #### Status values

doc/batch_json.schema.json

@@ -127,7 +127,7 @@
     },
 
     "cpu": {
-      "description": "CPU hardware identification. Null when --no-hw is active. Contains an 'arch' discriminator ('x86' or 'arm') and a matching arch-specific sub-object with identification fields and capabilities.",
+      "description": "CPU hardware identification. Null when --no-hw is active or when --arch-prefix is set (host CPU info is then suppressed to avoid mixing with a different-arch target kernel). Contains an 'arch' discriminator ('x86' or 'arm') and a matching arch-specific sub-object with identification fields and capabilities.",
       "oneOf": [
         { "type": "null" },
         {
@@ -180,16 +180,16 @@
                   "type": ["string", "null"]
                 },
                 "capabilities": {
-                  "description": "CPU feature flags detected via CPUID and MSR reads. Each value is true (present), false (absent), or null (not applicable or could not be read).",
+                  "description": "CPU feature flags detected via CPUID and MSR reads. Every value is tri-state: true=present, false=absent, null=not applicable or unreadable.",
                   "type": "object",
                   "additionalProperties": false,
                   "properties": {
                     "spec_ctrl":                      { "type": ["boolean", "null"], "description": "SPEC_CTRL MSR present (Intel; enables IBRS + IBPB via WRMSR)" },
-                    "ibrs":                           { "type": ["boolean", "null"], "description": "Indirect Branch Restricted Speculation" },
-                    "ibpb":                           { "type": ["boolean", "null"], "description": "Indirect Branch Prediction Barrier" },
+                    "ibrs":                           { "type": ["boolean", "null"], "description": "IBRS supported (via SPEC_CTRL, IBRS_SUPPORT, or cpuinfo fallback)" },
+                    "ibpb":                           { "type": ["boolean", "null"], "description": "IBPB supported (via SPEC_CTRL, IBPB_SUPPORT, or cpuinfo fallback)" },
                     "ibpb_ret":                       { "type": ["boolean", "null"], "description": "IBPB on return (enhanced form)" },
-                    "stibp":                          { "type": ["boolean", "null"], "description": "Single Thread Indirect Branch Predictors" },
-                    "ssbd":                           { "type": ["boolean", "null"], "description": "Speculative Store Bypass Disable" },
+                    "stibp":                          { "type": ["boolean", "null"], "description": "STIBP supported (Intel/AMD/HYGON or cpuinfo fallback)" },
+                    "ssbd":                           { "type": ["boolean", "null"], "description": "SSBD supported (SPEC_CTRL, VIRT_SPEC_CTRL, non-architectural MSR, or cpuinfo fallback)" },
                     "l1d_flush":                      { "type": ["boolean", "null"], "description": "L1D cache flush instruction" },
                     "md_clear":                       { "type": ["boolean", "null"], "description": "VERW clears CPU buffers (MDS mitigation)" },
                     "arch_capabilities":              { "type": ["boolean", "null"], "description": "IA32_ARCH_CAPABILITIES MSR is present" },
@@ -231,7 +231,7 @@
                     "tsa_l1_no":                      { "type": ["boolean", "null"], "description": "Not susceptible to TSA-L1" },
                     "verw_clear":                     { "type": ["boolean", "null"], "description": "VERW clears CPU buffers" },
                     "autoibrs":                       { "type": ["boolean", "null"], "description": "AMD AutoIBRS (equivalent to enhanced IBRS on Intel)" },
-                    "sbpb":                           { "type": ["boolean", "null"], "description": "Selective Branch Predictor Barrier (AMD Inception mitigation)" },
+                    "sbpb":                           { "type": ["boolean", "null"], "description": "Selective Branch Predictor Barrier (AMD Inception mitigation): true if PRED_CMD MSR SBPB bit write succeeded; false if write failed; null if not verifiable (non-root, CPUID error, or CPU does not report SBPB support)" },
                     "avx2":                           { "type": ["boolean", "null"], "description": "AVX2 supported (relevant to Downfall / GDS)" },
                     "avx512":                         { "type": ["boolean", "null"], "description": "AVX-512 supported (relevant to Downfall / GDS)" }
                   }

doc/batch_nrpe.md

@@ -51,6 +51,7 @@ STATUS: summary | perfdata
 | VULN + UNK | `N/T CVE(s) vulnerable: CVE-A CVE-B ..., M inconclusive` |
 | UNK only | `N/T CVE checks inconclusive` |
 | Non-root + VULN | `N/T CVE(s) appear vulnerable (unconfirmed, not root): CVE-A ...` |
+| Non-root + VULN + UNK | `N/T CVE(s) appear vulnerable (unconfirmed, not root): CVE-A ..., M inconclusive` |
 
 ### Lines 2+ (long output)
 
@@ -59,15 +60,19 @@ Never parsed by the monitoring core; safe to add or reorder.
 
 #### Context notes
 
-Printed before per-CVE details when applicable:
+Printed before per-CVE details when applicable.  Notes are emitted in this
+order when more than one applies:
 
 | Note | Condition |
 |---|---|
 | `NOTE: paranoid mode active, stricter mitigation requirements applied` | `--paranoid` was used |
-| `NOTE: hypervisor host detected (reason); L1TF/MDS severity is elevated` | System is a VM host (KVM, Xen, VMware…) |
+| `NOTE: hypervisor host detected (reason); L1TF/MDS severity is elevated` | System is detected as a VM host (KVM, Xen, VMware…) |
 | `NOTE: not a hypervisor host` | System is confirmed not a VM host |
 | `NOTE: not running as root; MSR reads skipped, results may be incomplete` | Script ran without root privileges |
 
+When VMM detection did not run (e.g. `--no-hw`), neither the
+`hypervisor host detected` nor the `not a hypervisor host` note is printed.
+
 #### Per-CVE detail lines
 
 One line per non-OK CVE.  VULN entries (`[CRITICAL]`) appear before UNK

doc/batch_prometheus.md

@@ -59,7 +59,7 @@ Script metadata.  Always value `1`; all data is in labels.
 | Label | Values | Meaning |
 |---|---|---|
 | `version` | string | Script version (e.g. `25.30.0250400123`) |
-| `mode` | `live` / `offline` | `live` = running on the active kernel; `offline` = inspecting a kernel image |
+| `mode` | `live` / `no-runtime` / `no-hw` / `hw-only` | Operating mode (see below) |
 | `run_as_root` | `true` / `false` | Whether the script ran as root.  Non-root scans skip MSR reads and may miss mitigations |
 | `paranoid` | `true` / `false` | `--paranoid` mode: stricter criteria (e.g. requires SMT disabled) |
 | `sysfs_only` | `true` / `false` | `--sysfs-only` mode: only the kernel's own sysfs report was used, not independent detection |
@@ -90,13 +90,16 @@ smc_build_info{version="25.30.0250400123",mode="live",run_as_root="true",paranoi
 
 Operating system and kernel metadata.  Always value `1`.
 
-Absent in offline mode when neither `uname -r` nor `uname -m` is available.
+Absent entirely when none of `kernel_release`, `kernel_arch`, or
+`hypervisor_host` can be determined (e.g. non-live mode with no VMM detection).
+Each label is emitted only when its value is known; missing labels are
+omitted rather than set to an empty string.
 
 | Label | Values | Meaning |
 |---|---|---|
-| `kernel_release` | string | Output of `uname -r` (live mode only) |
-| `kernel_arch` | string | Output of `uname -m` (live mode only) |
-| `hypervisor_host` | `true` / `false` | Whether this machine is detected as a hypervisor host (running KVM, Xen, VMware, etc.) |
+| `kernel_release` | string | Output of `uname -r`; emitted only in live mode |
+| `kernel_arch` | string | Output of `uname -m`; emitted only in live mode |
+| `hypervisor_host` | `true` / `false` | Whether this machine is detected as a hypervisor host (running KVM, Xen, VMware, etc.); absent when VMM detection did not run (e.g. `--no-hw`) |
 
 **Example:**
 ```
@@ -114,26 +117,47 @@ a malicious guest.  Always prioritise remediation on hosts where
 ### `smc_cpu_info`
 
 CPU hardware and microcode metadata.  Always value `1`.  Absent when `--no-hw`
-is used.
+is used or when `--arch-prefix` is set (host CPU info is suppressed to avoid
+mixing with a different-arch target kernel).
+
+Common labels (always emitted when the data is available):
 
 | Label | Values | Meaning |
 |---|---|---|
-| `vendor` | string | CPU vendor (e.g. `Intel`, `AuthenticAMD`) |
+| `vendor` | string | CPU vendor (e.g. `GenuineIntel`, `AuthenticAMD`, `HygonGenuine`, `ARM`) |
 | `model` | string | CPU friendly name from `/proc/cpuinfo` |
+| `arch` | `x86` / `arm` | Architecture family; determines which arch-specific labels follow |
+| `smt` | `true` / `false` | Whether SMT (HyperThreading) is currently enabled; absent if undeterminable |
+| `microcode` | hex string | Installed microcode version (e.g. `0xf4`); absent if unreadable |
+| `microcode_latest` | hex string | Latest known-good microcode version from the firmware database; absent if the CPU is not in the database |
+| `microcode_up_to_date` | `true` / `false` | Whether `microcode == microcode_latest`; absent if either is unavailable |
+| `microcode_blacklisted` | `true` / `false` | Whether the installed microcode is known to cause problems and should be rolled back; emitted whenever `microcode` is emitted |
+
+x86-only labels (emitted when `arch="x86"`):
+
+| Label | Values | Meaning |
+|---|---|---|
 | `family` | integer string | CPU family number |
 | `model_id` | integer string | CPU model number |
 | `stepping` | integer string | CPU stepping number |
-| `cpuid` | hex string | Full CPUID value (e.g. `0x000906ed`); absent on some ARM CPUs |
-| `codename` | string | Intel CPU codename (e.g. `Coffee Lake`); absent on AMD and ARM |
-| `smt` | `true` / `false` | Whether SMT (HyperThreading) is currently enabled |
-| `microcode` | hex string | Installed microcode version (e.g. `0xf4`) |
-| `microcode_latest` | hex string | Latest known-good microcode version from the firmware database |
-| `microcode_up_to_date` | `true` / `false` | Whether `microcode == microcode_latest` |
-| `microcode_blacklisted` | `true` / `false` | Whether the installed microcode is known to cause problems and should be rolled back |
+| `cpuid` | hex string | Full CPUID value (e.g. `0x000906ed`) |
+| `codename` | string | Intel CPU codename (e.g. `Coffee Lake`); absent on AMD/Hygon |
 
-**Example:**
+ARM-only labels (emitted when `arch="arm"`):
+
+| Label | Values | Meaning |
+|---|---|---|
+| `part_list` | string | Space-separated list of ARM part numbers across cores (e.g. `0xd0b 0xd05` on big.LITTLE) |
+| `arch_list` | string | Space-separated list of ARM architecture levels across cores (e.g. `8 8`) |
+
+**x86 example:**
 ```
-smc_cpu_info{vendor="Intel",model="Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz",family="6",model_id="158",stepping="13",cpuid="0x000906ed",codename="Coffee Lake",smt="true",microcode="0xf4",microcode_latest="0xf4",microcode_up_to_date="true",microcode_blacklisted="false"} 1
+smc_cpu_info{vendor="GenuineIntel",model="Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz",arch="x86",family="6",model_id="158",stepping="13",cpuid="0x000906ed",codename="Coffee Lake",smt="true",microcode="0xf4",microcode_latest="0xf4",microcode_up_to_date="true",microcode_blacklisted="false"} 1
+```
+
+**ARM example:**
+```
+smc_cpu_info{vendor="ARM",model="ARM v8 model 0xd0b",arch="arm",part_list="0xd0b 0xd05",arch_list="8 8",smt="false"} 1
 ```
 
 **Microcode labels:**
@@ -340,16 +364,28 @@ smc_vulnerability_status == 1
 
 ## Caveats and edge cases
 
-**Offline mode (`--kernel`)**
+**No-runtime mode (`--no-runtime`)**
 `smc_system_info` will have no `kernel_release` or `kernel_arch` labels (those
 come from `uname`, which reports the running kernel, not the inspected one).
-`mode="offline"` in `smc_build_info` signals this.  Offline mode is primarily
-useful for pre-deployment auditing, not fleet runtime monitoring.
+`mode="no-runtime"` in `smc_build_info` signals this.  No-runtime mode is
+primarily useful for pre-deployment auditing, not fleet runtime monitoring.
 
-**`--no-hw`**
+**No-hardware mode (`--no-hw`)**
 `smc_cpu_info` is not emitted.  CPU and microcode labels are absent from all
 queries.  CVE checks that rely on hardware capability detection (`cap_*` flags,
-MSR reads) will report `unknown` status.
+MSR reads) will report `unknown` status.  `mode="no-hw"` in `smc_build_info`
+signals this.
+
+**Cross-arch inspection (`--arch-prefix`)**
+When a cross-arch toolchain prefix is passed, the script suppresses the host
+CPU metadata so it does not get mixed with data from a different-arch target
+kernel: `smc_cpu_info` is not emitted, the same as under `--no-hw`.
+
+**Hardware-only mode (`--hw-only`)**
+Only hardware detection is performed; CVE checks are skipped.  `smc_cpu_info`
+is emitted but no `smc_vulnerability_status` metrics appear (and
+`smc_vulnerable_count` / `smc_unknown_count` are `0`).  `mode="hw-only"` in
+`smc_build_info` signals this.
 
 **`--sysfs-only`**
 The script trusts the kernel's sysfs report (`/sys/devices/system/cpu/vulnerabilities/`)