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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun,  4 Feb 2024 16:01:42 +0800
From: Shuai Xue <xueshuai@...ux.alibaba.com>
To: bp@...en8.de,
	rafael@...nel.org,
	wangkefeng.wang@...wei.com,
	tanxiaofei@...wei.com,
	mawupeng1@...wei.com,
	tony.luck@...el.com,
	linmiaohe@...wei.com,
	naoya.horiguchi@....com,
	james.morse@....com,
	gregkh@...uxfoundation.org,
	will@...nel.org,
	jarkko@...nel.org
Cc: linux-acpi@...r.kernel.org,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	linux-edac@...r.kernel.org,
	x86@...nel.org,
	xueshuai@...ux.alibaba.com,
	justin.he@....com,
	ardb@...nel.org,
	ying.huang@...el.com,
	ashish.kalra@....com,
	baolin.wang@...ux.alibaba.com,
	tglx@...utronix.de,
	mingo@...hat.com,
	dave.hansen@...ux.intel.com,
	lenb@...nel.org,
	hpa@...or.com,
	robert.moore@...el.com,
	lvying6@...wei.com,
	xiexiuqi@...wei.com,
	zhuo.song@...ux.alibaba.com
Subject: [PATCH v11 1/3] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered

Synchronous error was detected as a result of user-space process accessing
a 2-bit uncorrected error. The CPU will take a synchronous error exception
such as Synchronous External Abort (SEA) on Arm64. The kernel will queue a
memory_failure() work which poisons the related page, unmaps the page, and
then sends a SIGBUS to the process, so that a system wide panic can be
avoided.

However, no memory_failure() work will be queued when abnormal synchronous
errors occur. These errors can include situations such as invalid PA,
unexpected severity, no memory failure config support, invalid GUID
section, etc. In such case, the user-space process will trigger SEA again.
This loop can potentially exceed the platform firmware threshold or even
trigger a kernel hard lockup, leading to a system reboot.

Fix it by performing a force kill if no memory_failure() work is queued
for synchronous errors.

Signed-off-by: Shuai Xue <xueshuai@...ux.alibaba.com>
---
 drivers/acpi/apei/ghes.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 7b7c605166e0..0892550732d4 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -806,6 +806,15 @@ static bool ghes_do_proc(struct ghes *ghes,
 		}
 	}
 
+	/*
+	 * If no memory failure work is queued for abnormal synchronous
+	 * errors, do a force kill.
+	 */
+	if (sync && !queued) {
+		pr_err("Sending SIGBUS to current task due to memory error not recovered");
+		force_sig(SIGBUS);
+	}
+
 	return queued;
 }
 
-- 
2.39.3


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ