linux-kernel - [PATCH] panic: move bust_spinlocks(0) after console_flush_on

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: <1528091179-3015-1-git-send-email-hoeun.ryu@lge.com.com>
Date:   Mon,  4 Jun 2018 14:45:57 +0900
From:   Hoeun Ryu <hoeun.ryu@....com.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Borislav Petkov <bp@...e.de>, Andi Kleen <ak@...ux.intel.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>
Cc:     Hoeun Ryu <hoeun.ryu@....com>, linux-kernel@...r.kernel.org
Subject: [PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

From: Hoeun Ryu <hoeun.ryu@....com>

 Many console device drivers hold the uart_port->lock spinlock with irq enabled
(using spin_lock()) while the device drivers are writing characters to their devices,
but the device drivers just try to hold the spin lock (using spin_trylock()) if
"oops_in_progress" is equal or greater than 1 to avoid deadlocks.

 There is a case ocurring a deadlock related to the lock and oops_in_progress. A CPU
could be stopped by smp_send_stop() while it was holding the port lock because irq was
enabled. Once a CPU stops, it doesn't respond interrupts anymore and the lock stays
locked forever.

 console_flush_on_panic() is called during panic() and it eventually holds the uart
lock but the lock is held by another stopped CPU and it is a deadlock. By moving
bust_spinlocks(0) after console_flush_on_panic(), let the console device drivers
think the Oops is still in progress to call spin_trylock() instead of spin_lock() to
avoid the deadlock.

Signed-off-by: Hoeun Ryu <hoeun.ryu@....com>
---
 kernel/panic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index 42e4874..b4063b6 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -233,8 +233,6 @@ void panic(const char *fmt, ...)
 	if (_crash_kexec_post_notifiers)
 		__crash_kexec(NULL);

-	bust_spinlocks(0);
-
 	/*
 	 * We may have ended up stopping the CPU holding the lock (in
 	 * smp_send_stop()) while still having some valuable data in the console
@@ -246,6 +244,8 @@ void panic(const char *fmt, ...)
 	debug_locks_off();
 	console_flush_on_panic();

+	bust_spinlocks(0);
+
 	if (!panic_blink)
 		panic_blink = no_blink;

-- 
2.1.4