linux-kernel - [PATCH v2] x86/split_lock: Handle unexpected split lock as fatal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260107134955.3293885-1-xiaoyao.li@intel.com>
Date: Wed,  7 Jan 2026 21:49:55 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	x86@...nel.org
Cc: "H. Peter Anvin" <hpa@...or.com>,
	reinette.chatre@...el.com,
	Kiryl Shutsemau <kas@...nel.org>,
	rick.p.edgecombe@...el.com,
	linux-kernel@...r.kernel.org,
	xiaoyao.li@...el.com,
	chenyi.qiang@...el.com,
	chao.p.peng@...el.com
Subject: [PATCH v2] x86/split_lock: Handle unexpected split lock as fatal

The kernel can receive #AC fault on split lock access even when
X86_FEATURE_SPLIT_LOCK_DETECT is not enumerated. For example, this can
occur with a TDX guest running under a Linux host with split lock
detection enabled.

The default "warning" mode of handling user split lock depends on being
able to temporarily disable detection to recover from the split lock event.
However, when X86_FEATURE_SPLIT_LOCK_DETECT is not enumerated, the MSR
or the bit that disables detection is normally not accessible. This means
the feature cannot be disabled and the "warning" mode will not work. The
"fatal" mode, however, can still work properly.

Handle split locks as fatal in such cases.

Signed-off-by: Xiaoyao Li <xiaoyao.li@...el.com>
---
Changes in v2:
- handle it generally instead of special-casing TDX guest; [Kiryl]

v1: https://lore.kernel.org/all/20251126100205.1729391-1-xiaoyao.li@intel.com/

Notes:
- Kiryl suggested to check cpu_model_supports_sld in v1, while this v2
  checks X86_FEATURE_SPLIT_LOCK_DETECT. Because I found the latter can
  cover the purpose of the former in current kernel. I also sent a patch
  separately to clean up cpu_model_supports_sld. [1]

- Patch 2 of v1 is dropped in this v2, since v2 is not TDX specific
  anymore. If anyone has interest on whether to enhance sld_state_show()
  to call out the potential unexpected #AC behavior for TDX guest or
  for more general cases, we can discuss here.

[1] https://lore.kernel.org/all/20251218080044.2615106-1-xiaoyao.li@intel.com/
---
 arch/x86/kernel/cpu/bus_lock.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
index dbc99a47be45..68721f1a2cb0 100644
--- a/arch/x86/kernel/cpu/bus_lock.c
+++ b/arch/x86/kernel/cpu/bus_lock.c
@@ -316,9 +316,25 @@ void bus_lock_init(void)
 	wrmsrq(MSR_IA32_DEBUGCTLMSR, val);
 }
 
+static bool split_lock_fatal(void)
+{
+	/*
+	 * If #AC occurs on split lock without X86_FEATURE_SPLIT_LOCK_DETECT
+	 * the kernel cannot handle it by disabling the detection. Treat it as
+	 * fatal regardless of the sld_state.
+	 */
+	if (!cpu_feature_enabled(X86_FEATURE_SPLIT_LOCK_DETECT))
+		return true;
+
+	if (sld_state == sld_fatal)
+		return true;
+
+	return false;
+}
+
 bool handle_user_split_lock(struct pt_regs *regs, long error_code)
 {
-	if ((regs->flags & X86_EFLAGS_AC) || sld_state == sld_fatal)
+	if ((regs->flags & X86_EFLAGS_AC) || split_lock_fatal())
 		return false;
 	split_lock_warn(regs->ip);
 	return true;
-- 
2.43.0