linux-stable.git/arch/x86/kernel/cpu/amd.c, branch linux-5.10.y

x86/CPU/AMD: Move the Zen3 BTC_NO detection to the Zen3 init function

2026-06-19T11:21:49+00:00

commit affc66cb96f865b3763a8e18add52e133d864f04 upstream.

No functional changes.

Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Nikolay Borisov 
Link: http://lore.kernel.org/r/20231120104152.13740-4-bp@alien8.de
Stable-dep-of: 7c81ad8e8bc2 ("x86/CPU/AMD: Rename init_amd_zn() to init_amd_zen_common()")
[bwh: Adjusted to apply after backports of the above commit which actually
 depended on this]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache

2026-05-15T12:48:07+00:00

commit c21b90f77687075115d989e53a8ec5e2bb427ab1 upstream.

Make sure resources are not improperly shared in the op cache and
cause instruction corruption this way.

Signed-off-by: Prathyushi Nangia 
Co-developed-by: Borislav Petkov (AMD) 
Signed-off-by: Borislav Petkov (AMD) 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

x86/CPU/AMD: Add X86_FEATURE_ZEN1

2026-05-15T12:48:07+00:00

Commit 232afb557835d6f6859c73bf610bad308c96b131 upstream.

Add a synthetic feature flag specifically for first generation Zen
machines. There's need to have a generic flag for all Zen generations so
make X86_FEATURE_ZEN be that flag.

Fixes: 30fa92832f40 ("x86/CPU/AMD: Add ZenX generations flags")
Suggested-by: Brian Gerst 
Suggested-by: Tom Lendacky 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/dc3835e3-0731-4230-bbb9-336bbe3d042b@amd.com
Signed-off-by: Greg Kroah-Hartman

x86/CPU/AMD: Rename init_amd_zn() to init_amd_zen_common()

2026-05-15T12:48:07+00:00

Commit 7c81ad8e8bc28a1847e87c5afe1bae6bffb2f73e upstream.

Call it from all Zen init functions.

Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Nikolay Borisov 
Link: http://lore.kernel.org/r/20231120104152.13740-7-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman

x86/CPU/AMD: Call the spectral chicken in the Zen2 init function

2026-05-15T12:48:07+00:00

Commit cfbf4f992bfce1fa9f2f347a79cbbea0368e7971 upstream.

No functional change.

Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Nikolay Borisov 
Link: http://lore.kernel.org/r/20231120104152.13740-6-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman

x86/CPU/AMD: Add ZenX generations flags

2026-05-15T12:48:07+00:00

Commit 30fa92832f405d5ac9f263e99f62445fa3084008 upstream.

Add X86_FEATURE flags for each Zen generation. They should be used from
now on instead of checking f/m/s.

Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Nikolay Borisov 
Acked-by: Thomas Gleixner 
Link: http://lore.kernel.org/r/20231120104152.13740-2-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman

x86/CPU: Fix FPDSS on Zen1

2026-04-18T08:31:17+00:00

commit e55d98e7756135f32150b9b8f75d580d0d4b2dd3 upstream.

Zen1's hardware divider can leave, under certain circumstances, partial
results from previous operations.  Those results can be leaked by
another, attacker thread.

Fix that with a chicken bit.

Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

x86/bugs: Fix use of possibly uninit value in amd_check_tsa_microcode()

2025-08-28T14:22:30+00:00

For kernels compiled with CONFIG_INIT_STACK_NONE=y, the value of __reserved
field in zen_patch_rev union on the stack may be garbage.  If so, it will
prevent correct microcode check when consulting p.ucode_rev, resulting in
incorrect mitigation selection.

This is a stable-only fix.

Cc: 
Signed-off-by: Michael Zhivich 
Fixes: 78192f511f40 ("x86/bugs: Add a Transient Scheduler Attacks mitigation")
Signed-off-by: Greg Kroah-Hartman

x86/bugs: Add a Transient Scheduler Attacks mitigation

2025-07-17T16:28:00+00:00

From: "Borislav Petkov (AMD)" 

Commit d8010d4ba43e9f790925375a7de100604a5e2dba upstream.

Add the required features detection glue to bugs.c et all in order to
support the TSA mitigation.

Co-developed-by: Kim Phillips 
Signed-off-by: Kim Phillips 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Pawan Gupta 
Signed-off-by: Greg Kroah-Hartman

x86/cpu: Don't clear X86_FEATURE_LAHF_LM flag in init_amd_k8() on AMD when running in a virtual machine

2025-05-02T05:40:47+00:00

[ Upstream commit a4248ee16f411ac1ea7dfab228a6659b111e3d65 ]

When running in a virtual machine, we might see the original hardware CPU
vendor string (i.e. "AuthenticAMD"), but a model and family ID set by the
hypervisor. In case we run on AMD hardware and the hypervisor sets a model
ID < 0x14, the LAHF cpu feature is eliminated from the the list of CPU
capabilities present to circumvent a bug with some BIOSes in conjunction with
AMD K8 processors.

Parsing the flags list from /proc/cpuinfo seems to be happening mostly in
bash scripts and prebuilt Docker containers, as it does not need to have
additionals tools present – even though more reliable ways like using "kcpuid",
which calls the CPUID instruction instead of parsing a list, should be preferred.
Scripts, that use /proc/cpuinfo to determine if the current CPU is
"compliant" with defined microarchitecture levels like x86-64-v2 will falsely
claim the CPU is incapable of modern CPU instructions when "lahf_lm" is missing
in that flags list.

This can prevent some docker containers from starting or build scripts to create
unoptimized binaries.

Admittably, this is more a small inconvenience than a severe bug in the kernel
and the shoddy scripts that rely on parsing /proc/cpuinfo
should be fixed instead.

This patch adds an additional check to see if we're running inside a
virtual machine (X86_FEATURE_HYPERVISOR is present), which, to my
understanding, can't be present on a real K8 processor as it was introduced
only with the later/other Athlon64 models.

Example output with the "lahf_lm" flag missing in the flags list
(should be shown between "hypervisor" and "abm"):

    $ cat /proc/cpuinfo
    processor       : 0
    vendor_id       : AuthenticAMD
    cpu family      : 15
    model           : 6
    model name      : Common KVM processor
    stepping        : 1
    microcode       : 0x1000065
    cpu MHz         : 2599.998
    cache size      : 512 KB
    physical id     : 0
    siblings        : 1
    core id         : 0
    cpu cores       : 1
    apicid          : 0
    initial apicid  : 0
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 13
    wp              : yes
    flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
                      cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp
                      lm rep_good nopl cpuid extd_apicid tsc_known_freq pni
                      pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt
                      tsc_deadline_timer aes xsave avx f16c hypervisor abm
                      3dnowprefetch vmmcall bmi1 avx2 bmi2 xsaveopt

... while kcpuid shows the feature to be present in the CPU:

    # kcpuid -d | grep lahf
         lahf_lm             - LAHF/SAHF available in 64-bit mode

[ mingo: Updated the comment a bit, incorporated Boris's review feedback. ]

Signed-off-by: Max Grobecker 
Signed-off-by: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
Cc: Borislav Petkov 
Signed-off-by: Sasha Levin