linux.git/arch/x86/kernel/cpu, branch v7.2

x86/CPU: Add a tlbi= cmdline switch

2026-08-10T14:09:18+00:00

With the recently found INVLPGB / TLBSYNC issue, there has been some
interest in disabling INVLPGB-based TLB flushing, in order to rule out
that CPU issue as a cause of userspace crashes.

Add a kernel command line option to control the TLB flushing behavior.

If the need arises, we will add a "tlbi=broadcast" for the case when TLB
invalidation broadcasts need to be explicitly selected, but this is not
needed now yet.

  [ bp: Rewrite commit message, move to cpu/common.c, add documentation. ]

Fixes: 767ae437a32d ("x86/mm: Add INVLPGB feature and Kconfig entry")
Suggested-by: Borislav Petkov 
Signed-off-by: Rik van Riel 
Signed-off-by: Borislav Petkov (AMD) 
Cc: 
Link: https://patch.msgid.link/20260729204341.3eb0b5ea@fangorn

Merge tag 'x86-urgent-2026-08-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-08T23:43:07+00:00

Pull x86 fix from Ingo Molnar:

 - Fix MCE CMCI discovery initialization ordering bug (Breno Leitao)

* tag 'x86-urgent-2026-08-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mce: Set up the polling timer before CMCI discovery

Merge tag 'x86_bugs_saferet' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-06T00:02:58+00:00

 - Add a mitigation for the attack vector of interrupting the saferet
   sequence used in the SRSO mitigation and still poisoning the RSB.

   Do that by emulating the saferet sequence and thus avoiding executing
   a RET instruction.

* tag 'x86_bugs_saferet' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/bugs: Make Safe-RET robust against interrupt injection

x86/mce: Set up the polling timer before CMCI discovery

2026-08-04T22:09:25+00:00

I hit the following on one of my machines:

  mce: CPU0 BANK15 CMCI inherited storm
  ------------[ cut here ]------------
  ODEBUG: assert_init not available (active state 0) object: (____ptrval____) object type: timer_list hint: 0x0
  WARNING: lib/debugobjects.c:632 at debug_object_assert_init+0x178/0x230, CPU#0: swapper/0/0
  CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #3 PREEMPTLAZY
  RIP: 0010:debug_object_assert_init+0x18f/0x230
  Call Trace:
   
   __mod_timer
   mce_timer_kick
   cmci_discover
   intel_init_cmci
   mce_intel_feature_init
   mcheck_cpu_init
   identify_cpu
   identify_boot_cpu
   arch_cpu_finalize_init
   start_kernel

A second splat follows right after, from timer_setup() finding that same
timer already queued:

  ODEBUG: init active (active state 0) object: (____ptrval____) object type: timer_list hint: stub_timer+0x0/0x10

This is happening because CMCI storm detection is trying to modify the timer
before latter was properly set up.

Set up the timer first. __mcheck_cpu_setup_timer() only calls timer_setup(),
and depends on neither the generic nor the vendor init.

  [ bp: Massage commit message. ]

Fixes: 1f68ce2a0272 ("x86/mce: Handle Intel threshold interrupt storms")
Signed-off-by: Breno Leitao 
Signed-off-by: Borislav Petkov (AMD) 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260803-mce_timer_init-v1-1-9539db424330@debian.org

x86/CPU/AMD: Carve out a Zen5 models range

2026-07-29T19:52:27+00:00

Family 0x1a, model 0xd0..0xd7 belongs to the Zen5 generation. Carve it
out from the larger, Zen6 range where former doesn't belong.

  [ bp: Rewrite commit message, add tags. ]

Fixes: b5f53e6d3d32 ("x86/CPU/AMD: Add more Zen6 models")
Signed-off-by: Pratik Vishwakarma 
Signed-off-by: Borislav Petkov (AMD) 
Cc: 
Link: https://patch.msgid.link/20260729055459.15904-1-Pratik.Vishwakarma@amd.com

x86/bugs: Make Safe-RET robust against interrupt injection

2026-07-26T14:21:37+00:00

An attacker injecting interrupts while the Safe-RET mitigation executes
on machines affected by SRSO can neutralize the safe return sequence,
potentially leading to data leakage through speculative execution.

Fixup register state as if the Safe-RET sequence executed successfully
by "emulating" it, in a manner of speaking, and avoid executing a RET
instruction after returning from the interrupt.

Co-developed-by: David Kaplan 
Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD)

x86/cpu: Remove Makefile rule for removed UMC CPU support

2026-07-12T01:07:30+00:00

Support for UMC CPUs was removed in

  7d328c5de43a ("x86/cpu: Remove CPU_SUP_UMC_32 support"),

but a Makefile rule for the support code remained. Remove it.

Fixes: 7d328c5de43a ("x86/cpu: Remove CPU_SUP_UMC_32 support")
Signed-off-by: Ethan Nelson-Moore 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Ahmed S. Darwish 
Link: https://patch.msgid.link/20260610033252.164571-1-enelsonmoore@gmail.com

Merge tag 'x86-urgent-2026-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-07-05T15:37:46+00:00

Pull x86 fix from Ingo Molnar:

 - Prevent OOB access in the resctrl code while offlining
   CPUs when Intel SNC (Sub-NUMA Clustering) is enabled
   (Reinette Chatre)

* tag 'x86-urgent-2026-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled

x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled

2026-07-01T20:15:02+00:00

The architecture updates the cpu_mask in a domain's header to track which
online CPUs are associated with the domain. When this mask becomes empty
the architecture initiates offline of the domain that includes calling
on resctrl fs to offline the domain. If it is a monitoring domain in
which LLC occupancy is tracked resctrl fs forces the limbo handler to
clear all busy RMID state associated with the domain.

The limbo handler always reads the current event value associated with a
busy RMID irrespective of it being checked as part of regular "is it still
busy" check or whether it will be forced released anyway. When reading an
RMID on a system with SNC enabled the "logical RMID" is converted to the
"physical RMID" and this conversion requires the NUMA node ID of the
resctrl monitoring domain that is in turn determined by querying the NUMA
node ID of any CPU belonging to the monitoring domain.

When the monitoring domain is going offline its cpu_mask is empty causing
the NUMA node ID query via cpu_to_node() to be done with "nr_cpu_ids" as
argument resulting in an out-of-bounds access.

Refactor the limbo handler to skip reading the RMID when the RMID will
just be forced to no longer be dirty in the domain anyway. Add a safety
check to the architecture's RMID reader to protect against this scenario.

Fixes: e13db55b5a0d ("x86/resctrl: Introduce snc_nodes_per_l3_cache")
Closes: https://sashiko.dev/#/patchset/cover.1780456704.git.reinette.chatre%40intel.com?part=9
Reported-by: Sashiko 
Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Cc: 
Link: https://patch.msgid.link/16137433df42f85013b2f7a53626795cbd6637b9.1781029125.git.reinette.chatre@intel.com

x86/bugs: Enable IBPB flush on BPF JIT allocation

2026-07-01T08:33:38+00:00

Enable hardening against JIT spraying when Spectre-v2 mitigations are in
use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip
enabling the IBPB flush if the BPF dispatcher is already using a retpoline
sequence.

This hardening applies only when BPF-JIT is in use. Guard the enabling
under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n.

Signed-off-by: Pawan Gupta 
Acked-by: Daniel Borkmann 
Acked-by: Dave Hansen 
Signed-off-by: Daniel Borkmann