Intel Affected Processor List: Ambiguous Information

LG12 · ‎08-08-2025

Hi,

I've downloaded the latest Intel Affected Processor List from Github (https://github.com/intel/Intel-affected-processor-list), which is also linked on the following documentation page: https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html

I noticed that the provided CSV file containes two rows (25 and 26) for the "Tiger Lake H" microarchitecture, with all identifiers being identical (Family/Model, Stepping, Code Name, CPUID, MCU Update). However, the provided guidance is different for the "MMIO: Device Register Partial Write (DRPW) - CVE-2022-21166 - INTEL-SA-00615" vulnerability.

I was wondering whether those two rows refer to the same set of processors or not. If they do, which row is correct? If not, how can I distinguish "Tiger Lake H" processors that are affected by CVE-2022-21166 from those that are not?

Thanks,
Leo

TheExpertGuy · ‎08-11-2025

it’s possible that

Both rows refer to the same CPUID/stepping but represent different firmware/microcode states or OEM implementation differences

One entry could correspond to processors where the mitigation is already integrated in microcode, while the other applies to configurations still requiring an update

That said, without explicit clarification from Intel, it’s not possible to determine which row should be applied in your specific case just by looking at the CSV. The safest route is to:

Check your CPU’s exact model and stepping using wmic cpu get name, ProcessorId (Windows) or lscpu (Linux).
Compare that against Intel’s official Processor Identification Utility results.
Cross-reference your OEM’s firmware/microcode release notes — OEM-specific guidance often overrides the general CSV.
If in doubt, follow the most conservative mitigation guidance listed.

I’ll also recommend submitting this directly to Intel’s Security Center feedback or the GitHub repo’s issue tracker so they can confirm whether those entries should be merged or distinguished

LG12 · ‎08-11-2025

it’s possible that
Both rows refer to the same CPUID/stepping but represent different firmware/microcode states or OEM implementation differences
One entry could correspond to processors where the mitigation is already integrated in microcode, while the other applies to configurations still requiring an update

Isn't that what the "MCU Update" column is for? I thought MCU means "MicroCodeUpdate" (even though "MicroCodeUpdate Update" is a bit redundant then). If the two Tiger Lake rows describe the mitigation status for different microcode revisions, I would expect different values in the "MCU Update" column.

AlphaTop89 · ‎08-11-2025

...the duplicate-looking entries for “Tiger Lake H” in the affected processor CSV are definitely confusing. You’re right that the MCU Update column usually indicates the microcode revision that includes the mitigation, so if both rows list the same value there, it’s odd to see differing guidance for the same CPUID/stepping. The CSV may contain redundant rows due to legacy data import or parallel maintenance of guidance from multiple teams. Sometimes one set of guidance comes from the CPU architecture team and another from platform integration teams, and they don’t always consolidate perfectly. Even with identical MCU update numbers, some guidance can differ depending on platform SKU behavior (e.g., embedded vs. mobile vs. workstation variants) or whether the vulnerability can be exposed via certain chipset features.

Since you’re already aware of the MCU meaning, I agree that identical values there should typically imply identical mitigation status. That makes this a good candidate for direct clarification

I’d recommend:

Opening an issue in the GitHub repo for visibility, since that’s where the CSV is actively maintained.
If you need an official position quickly, submit the question via Intel’s Security Center with a link to the CSV and highlight the specific rows.

Until clarified, it’s safest to assume the stricter guidance applies to your processor, especially if your OEM firmware release notes don’t explicitly confirm mitigation.

LG12 · ‎08-12-2025

Alright, I've opened an issue on Github: https://github.com/intel/Intel-affected-processor-list/issues/4