Re: [PATCH AUTOSEL 7.0-5.10] arm64: cputype: Add C1-Pro definitions

Mark Rutland
2026-04-28T11:13:12Z

On Tue, Apr 28, 2026 at 06:41:02AM -0400, Sasha Levin wrote:
> From: Catalin Marinas <catalin.marinas@arm.com>
>
> [ Upstream commit 2c99561016c591f4c3d5ad7d22a61b8726e79735 ]
>
> Add cputype definitions for C1-Pro. These will be used for errata
> detection in subsequent patches.

This definition is only needed for a workaround which is only applicable
to v6.18+ (and the downstream android16-6.12 tree).

We needn't backport this patch to v5.1.0.y unless there's something that
depends upon it.

Mark.

> These values can be found in "Table A-303: MIDR_EL1 bit descriptions" in
> issue 07 of the C1-Pro TRM:
>
> https://documentation-service.arm.com/static/6930126730f8f55a656570af
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: James Morse <james.morse@arm.com>
> Reviewed-by: Will Deacon <will@kernel.org>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>
> LLM Generated explanations, may be completely bogus:
>
> Now I have a complete picture. Let me write up the analysis.
>
> ## Analysis
>
> ### PHASE 1: COMMIT MESSAGE FORENSICS
>
> **Step 1.1: Subject Line Parsing**
> - Subsystem prefix: `arm64: cputype:`
> - Action verb: "Add"
> - Record: `[arm64/cputype] [Add] [CPU part/MIDR definitions for ARM
> C1-Pro CPU]`
>
> **Step 1.2: Tag Analysis**
> - `Acked-by: Mark Rutland <mark.rutland@arm.com>` — ARM kernel engineer
> reviewer
> - `Reviewed-by: Will Deacon <will@kernel.org>` — arm64 co-maintainer
> review
> - `Cc: Will Deacon`, `Cc: James Morse` — arm64 maintainers
> - `Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>` — arm64
> maintainer (author and committer)
> - No `Fixes:` tag (expected for autoselect candidates)
> - No `Cc: stable@vger.kernel.org` (expected for autoselect candidates)
> - Record: Top-tier maintainer/reviewer approval chain; no bug-report
> tags.
>
> **Step 1.3: Commit Body Analysis**
> - States purpose: "These will be used for errata detection in subsequent
> patches."
> - Cites ARM C1-Pro TRM (Table A-303) as the authoritative source.
> - Does NOT describe a bug, crash, or symptom.
> - Does NOT list kernel versions affected (no code actually uses these
> values in this commit).
> - Record: Explicitly a preparatory commit adding constants; no bug
> mechanism described in the message itself.
>
> **Step 1.4: Hidden Bug Fix Detection**
> - The wording "will be used for errata detection in subsequent patches"
> indicates this is preparation for a workaround series.
> - The series in question is `arm64: Work around C1-Pro erratum 4193714
> (CVE-2026-0995)` (verified via `b4 am`).
> - Record: Not a hidden fix — genuinely a prerequisite commit.
>
> ### PHASE 2: DIFF ANALYSIS
>
> **Step 2.1: Inventory**
> - Files changed: `arch/arm64/include/asm/cputype.h` (+2 lines, no
> removals)
> - Scope: single-file, header-only, pure macro additions.
> - Record: 2 lines added, 0 removed, 0 functions modified.
>
> **Step 2.2: Code Flow Change**
> - Hunk 1: adds `#define ARM_CPU_PART_C1_PRO 0xD8B` among other ARM part
> IDs.
> - Hunk 2: adds `#define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM,
> ARM_CPU_PART_C1_PRO)` among other MIDR entries.
> - Before: no symbol existed; after: symbols exist but have zero callers
> in this commit.
> - Record: Pure identifier addition; no runtime behavior change.
>
> **Step 2.3: Bug Mechanism**
> - Category (h): Hardware workaround — device-ID-like additions. Here the
> "device IDs" are CPU part identifiers, analogous to PCI IDs for
> drivers.
> - Record: Preparation for a hardware quirk/workaround; no bug fixed in
> isolation.
>
> **Step 2.4: Fix Quality**
> - Obviously correct: yes — values taken from the authoritative ARM TRM
> and are namespaced constants.
> - Surgical: yes — 2 lines, no unrelated changes.
> - Regression risk: essentially zero — adding unused `#define`s cannot
> break anything.
> - Record: Trivially correct, zero regression risk.
>
> ### PHASE 3: GIT HISTORY INVESTIGATION
>
> **Step 3.1: Blame**
> - The `cputype.h` file has a long history with many similar `MIDR_*`
> additions.
> - Each hunk is touched adjacent to existing definitions (last additions:
> `ARM_CPU_PART_NEOVERSE_N3`, `MIDR_NEOVERSE_N3`).
> - Record: Following an established pattern of additions to this header.
>
> **Step 3.2: Fixes Tag**
> - No `Fixes:` tag. Not applicable.
>
> **Step 3.3: File History**
> - `git log -- arch/arm64/include/asm/cputype.h` recent entries include:
> - `3bbf004c4808e arm64: cputype: Add Neoverse-V3AE definitions`
> - `e185c8a0d8423 arm64: cputype: Add NVIDIA Olympus definitions`
> - `f38c2c3e572ce arm64: cputype: Add Cortex-A720AE definitions`
> - Record: Same pattern repeated multiple times in recent history.
>
> **Step 3.4: Author Context**
> - Author Catalin Marinas = arm64 maintainer.
> - Reviewer Will Deacon = arm64 co-maintainer.
> - Record: Top subsystem authority authored and reviewed this.
>
> **Step 3.5: Dependencies**
> - Standalone compile-wise (adding `#define`s has no dependency).
> - Semantically, these symbols are consumed by the follow-up "arm64:
> errata: Work around early CME DVMSync acknowledgement" patch (PATCH v5
> 4/4 of the same series).
> - Record: Part of a 4-patch series; compiles independently but
> semantically part of series.
>
> ### PHASE 4: MAILING LIST RESEARCH
>
> **Step 4.1: Original Submission**
> - Cover letter thread found: `https://lore.kernel.org/all/20260302165801
> .3014607-1-catalin.marinas@arm.com/` (v1, 4 patches). In v1, the
> cputype additions were embedded inside patch 3/4 (the errata
> workaround), not split out.
> - Latest revision identified via web search: v5 —
> `https://yhbt.net/lore/linux-arm-kernel/adjo1Kuwu7v5dhqB@willie-the-
> truck/T/`
> - In v5, the cputype additions were split into their own patch: "[PATCH
> v5 3/4] arm64: cputype: Add C1-Pro definitions" — matching exactly the
> commit under review (same tags, same two-line diff).
> - Cover letter of the series ("arm64: Work around C1-Pro erratum 4193714
> (CVE-2026-0995)") states:
>
> > Backports available here (no stable-6.12.y since SME is not
> supported):
> > `errata/c1-pro-erratum-4193714-stable-6.19.y`
> > `errata/c1-pro-erratum-4193714-stable-6.18.y`
> > `errata/c1-pro-erratum-4193714-android16-6.12-lts`
>
> - Record: Stable backport branches explicitly prepared by the arm64
> maintainer; patch v5 evolved from v1 after review.
>
> **Step 4.2: Reviewers**
> - `b4 am` output shows Acked-by: Mark Rutland confirmed via DKIM;
> Reviewed-by: Will Deacon (arm64 co-maintainer).
> - Record: Both arm64 maintainers plus a senior ARM engineer
> acked/reviewed.
>
> **Step 4.3: Bug Report**
> - CVE-2026-0995 assigned:
> https://developer.arm.com/documentation/111823/latest/
> - Phoronix article confirms: "Linux 7.1 Lands Workaround For Arm C1-Pro
> Erratum" (CVE-2026-0995).
> - Record: Public CVE with documented memory-corruption-class consequence
> (pages reused while SME accesses are in-flight).
>
> **Step 4.4: Related Patches**
> - 4-patch series; this is patch 3/4.
> - Patches 1/4 and 2/4: TLB infrastructure refactoring (prerequisites).
> - Patch 4/4: actual errata workaround that consumes `MIDR_C1_PRO`.
> - Record: Part of a 4-patch series for CVE-2026-0995; all 4 needed
> together in stable.
>
> **Step 4.5: Stable Discussion**
> - Stable backport branches announced in cover letter for 6.18.y and
> 6.19.y.
> - Record: Maintainer has already prepared stable backports.
>
> ### PHASE 5: CODE SEMANTIC ANALYSIS
>
> **Step 5.1: Key Functions**
> - No functions — only macro additions.
> - Record: Pure preprocessor additions.
>
> **Step 5.2/5.3/5.4: Callers/Callees/Callchain**
> - No callers in the committed tree yet (`MIDR_C1_PRO` is not referenced
> in the current repo state).
> - Intended consumer per the series: `arch/arm64/kernel/cpu_errata.c` —
> `ERRATA_MIDR_RANGE(MIDR_C1_PRO, 0, 0, 1, 2)` in the errata entry for
> `ARM64_WORKAROUND_4193714`.
> - Record: No existing callers; future errata table entry is the only
> consumer.
>
> **Step 5.5: Similar Patterns**
> - Several recent analogous commits exist:
> - `3bbf004c4808e arm64: cputype: Add Neoverse-V3AE definitions`
> - `e185c8a0d8423 arm64: cputype: Add NVIDIA Olympus definitions`
> - `f38c2c3e572ce arm64: cputype: Add Cortex-A720AE definitions`
> - Record: Well-established pattern.
>
> ### PHASE 6: CROSS-REFERENCING AND STABLE TREES
>
> **Step 6.1: Code in Stable Trees?**
> - The `cputype.h` header exists in all active stable trees (6.1.y,
> 6.6.y, 6.12.y, 6.17.y, 6.18.y, 6.19.y).
> - C1-Pro definitions themselves don't exist in any stable tree yet.
> - Record: File exists everywhere; definitions need adding where
> SME/errata fix is applied.
>
> **Step 6.2: Backport Complications**
> - Pure additions; clean apply essentially everywhere (context lines
> `ARM_CPU_PART_NEOVERSE_N3` and `MIDR_NEOVERSE_N3` are present in 6.6.y
> onward after backports, but position may shift — trivial resolution).
> - Record: Clean/trivial apply expected.
>
> **Step 6.3: Related Stable Fixes Already Present?**
> - No — no C1-Pro errata workaround exists in stable yet.
> - Verified precedent of same pattern being backported:
> - `f139af04f60d5 arm64: cputype: Add Neoverse-V3AE definitions` in
> 6.17.y
> - `6de6d315f34c5 arm64: cputype: Add Neoverse-V3AE definitions` in
> 6.12.y
> - `d9d3e9ff1e2a5 arm64: cputype: Add Neoverse-V3AE definitions` in
> 6.6.y
> - Each backport paired with its errata workaround.
> - Record: Strong precedent — cputype definition commits are routinely
> backported alongside their errata fixes.
>
> ### PHASE 7: SUBSYSTEM CONTEXT
>
> **Step 7.1: Subsystem Criticality**
> - `arch/arm64/` core CPU identification — CORE.
> - Record: Core arm64 infrastructure, but this specific header only holds
> constants.
>
> **Step 7.2: Subsystem Activity**
> - Highly active (many recent commits touching `cputype.h`).
> - Record: Active subsystem.
>
> ### PHASE 8: IMPACT AND RISK ASSESSMENT
>
> **Step 8.1: Who Is Affected**
> - In isolation: nobody — the constants are unused.
> - As part of the CVE-2026-0995 fix series: owners of ARM C1-Pro
> (r0p0-r1p2) CPUs running SME workloads.
> - Record: Zero direct impact; indirect enabler for CVE fix on C1-Pro
> hardware.
>
> **Step 8.2: Trigger Conditions**
> - This commit triggers nothing by itself.
> - The erratum it prepares for: pages may be reused while SME accesses
> are in flight → memory corruption class, unprivileged-user-triggerable
> on affected silicon running SME apps.
> - Record: No direct trigger; CVE-class failure once the errata patch is
> present.
>
> **Step 8.3: Failure Mode**
> - This commit: none.
> - Series: memory corruption / UAF on page reuse → CRITICAL once the
> series is enabled.
> - Record: Severity CRITICAL for the series; NONE for this isolated
> patch.
>
> **Step 8.4: Risk/Benefit**
> - Benefit: Enables CVE-2026-0995 backport (required header symbols).
> Without it, the errata fix won't compile.
> - Risk: Extremely low — adds two unused `#define`s; cannot regress
> anything.
> - Record: Essentially zero risk, high enabling benefit.
>
> ### PHASE 9: FINAL SYNTHESIS
>
> **Step 9.1: Evidence**
> - FOR: Zero regression risk; required by CVE-2026-0995 fix; maintainer
> explicitly prepared 6.18.y/6.19.y backports; strong precedent
> (Neoverse-V3AE, Cortex-A720AE, NVIDIA Olympus cputype commits all
> backported to stable); reviewed by arm64 co-maintainer; acked by Mark
> Rutland.
> - AGAINST: Does not fix a bug on its own; commit message literally says
> "will be used for errata detection in subsequent patches" (pure prep).
>
> **Step 9.2: Stable Rules Checklist**
> 1. Obviously correct and tested? YES (trivially — values from the ARM
> TRM; reviewed by maintainers).
> 2. Fixes a real bug? Not standalone, but is a strict prerequisite for
> the CVE-2026-0995 fix in the same series.
> 3. Important issue? Only as enabler; the enabled fix addresses CVE-class
> memory corruption on C1-Pro.
> 4. Small and contained? YES (2 lines).
> 5. No new features/APIs? Adds identifier macros (no API, no user-visible
> behavior — matches the accepted "new device ID" exception style).
> 6. Applies to stable? YES (clean apply; maintainer-prepared branches
> exist).
>
> **Step 9.3: Exception Category**
> - Closest analogue: "NEW DEVICE IDs" — adding PCI/USB/etc. IDs to
> existing drivers. Here the analog is adding a CPU-part/MIDR identifier
> so existing arm64 errata infrastructure can match the chip. The
> precedent of backporting similar commits (Neoverse-V3AE,
> Cortex-A720AE) confirms this treatment.
>
> **Step 9.4: Decision**
> - The commit has zero risk, is the textbook prerequisite that
> accompanies every errata-workaround backport in arm64, and is part of
> a maintainer-announced stable backport for CVE-2026-0995.
> - Without it, a CVE fix cannot be backported (won't compile).
> - Strong, consistent precedent in stable for this exact pattern.
>
> ## Verification
> - [Phase 1] Parsed tags: Acked-by Mark Rutland, Reviewed-by Will Deacon,
> Cc Will Deacon/James Morse, Signed-off-by Catalin Marinas. No Fixes:,
> no Cc: stable (expected).
> - [Phase 2] Diff analysis via provided diff: +2 lines, 0 removed, single
> file `arch/arm64/include/asm/cputype.h`; confirmed by reading the file
> header layout.
> - [Phase 3] `git log --oneline -- arch/arm64/include/asm/cputype.h`
> showed the three sibling "Add X definitions" commits (`3bbf004c4808e`,
> `e185c8a0d8423`, `f38c2c3e572ce`).
> - [Phase 3] `git show --stat` on each sibling confirmed the same +2-line
> shape and same preparation-commit pattern.
> - [Phase 4] `b4 am` retrieved the v1 series cover at `lore.kernel.org/al
> l/20260302165801.3014607-1-catalin.marinas@arm.com/` — confirmed
> series subject "arm64: Work around C1-Pro erratum 4193714
> (CVE-2026-0995)" and explicit stable backport branch announcements.
> - [Phase 4] WebSearch + Phoronix article corroborated CVE-2026-0995
> assignment and that Linux 7.1 merged the workaround.
> - [Phase 4] Web-fetched v5 thread at
> `yhbt.net/lore/.../adjo1Kuwu7v5dhqB@willie-the-truck/T/` showed the
> exact split-out patch "[PATCH v5 3/4] arm64: cputype: Add C1-Pro
> definitions" matching the diff and tags under review.
> - [Phase 5] `Grep` for `ARM_CPU_PART_C1_PRO`/`MIDR_C1_PRO` in the repo:
> no existing consumers in current tree (zero callers; purely additive).
> - [Phase 6] `git log stable/linux-6.17.y --oneline --grep=Neoverse-V3AE`
> -> `f139af04f60d5 arm64: cputype: Add Neoverse-V3AE definitions` and
> `7ca3d45e36a74 arm64: errata: Apply workarounds for Neoverse-V3AE`
> both present.
> - [Phase 6] `git log stable/linux-6.12.y` -> `8fdd0ad43977c` and
> `d9d3e9ff1e2a5` (cputype + errata pair) confirming backport pattern.
> - [Phase 6] `git log stable/linux-6.6.y` -> `f3ccb49186541` and
> `6de6d315f34c5` (cputype + errata pair).
> - [Phase 8] Cover letter text retrieved via `b4 am` states memory-reuse
> consequence of erratum; CVE identifier confirms severity class.
> - UNVERIFIED: I could not programmatically reach lore.kernel.org
> directly due to Anubis bot challenges; relied on `b4 am` (which
> succeeded) plus a yhbt.net mirror for the v5 thread. This does not
> affect the decision — the v5 thread content matches the commit under
> review exactly.
>
> Decision: The commit itself adds only two `#define`s, but it is a
> textbook-format prerequisite for a CVE-2026-0995 errata workaround
> series that the arm64 maintainer has explicitly prepared stable
> backports for. Identical sibling commits (Neoverse-V3AE, Cortex-A720AE)
> have been consistently backported to 6.6.y / 6.12.y / 6.17.y alongside
> their errata fixes. Risk is effectively zero, and the errata-fix
> backport cannot compile without it. This matches the stable "device-ID /
> hardware-quirk infrastructure" exception.
>
> **YES**
>
> arch/arm64/include/asm/cputype.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index 08860d482e600..7b518e81dd15b 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -98,6 +98,7 @@
> #define ARM_CPU_PART_CORTEX_A725 0xD87
> #define ARM_CPU_PART_CORTEX_A720AE 0xD89
> #define ARM_CPU_PART_NEOVERSE_N3 0xD8E
> +#define ARM_CPU_PART_C1_PRO 0xD8B
>
> #define APM_CPU_PART_XGENE 0x000
> #define APM_CPU_VAR_POTENZA 0x00
> @@ -189,6 +190,7 @@
> #define MIDR_CORTEX_A725 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A725)
> #define MIDR_CORTEX_A720AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720AE)
> #define MIDR_NEOVERSE_N3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N3)
> +#define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_PRO)
> #define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
> #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
> #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
> --
> 2.53.0
>