linux-kernel - [PATCH] sysrq: Use panic() to force a crash

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]

Date:   Tue, 18 Sep 2018 17:31:47 -0700
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>
Cc:     linux-kernel@...r.kernel.org, Evan Green <evgreen@...omium.org>,
        Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
        Douglas Anderson <dianders@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Manoj Gupta <manojgupta@...omium.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Ani Sinha <ani@...sta.com>,
        Matthias Kaehlcke <mka@...omium.org>
Subject: [PATCH] sysrq: Use panic() to force a crash

sysrq_handle_crash() currently forces a crash by dereferencing a
NULL pointer, which is undefined behavior in C. Just call panic()
instead, which is simpler and doesn't depend on compiler specific
handling of the undefined behavior.

Suggested-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Signed-off-by: Matthias Kaehlcke <mka@...omium.org>
---
Not sure if it is strictly needed to release the RCU read lock now
that panic() is invoked directly (I couldn't repro the warning
without rcu_read_unlock()), but since this is a forced crash it
seems good practice to keep doing it.

The commit that added rcu_read_unlock() and the comment is:

commit 984cf355aeaa8f2eda3861b50d0e8d3e3f77e83b
Author: Ani Sinha <ani@...sta.com>
Date:   Thu Dec 17 17:15:10 2015 -0800

    sysrq: Fix warning in sysrq generated crash.

    Commit 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq") replaced
    spin_lock_irqsave() calls with rcu_read_lock() calls in sysrq. Since
    rcu_read_lock() does not disable preemption, faulthandler_disabled() in
    __do_page_fault() in x86/fault.c returns false. When the code later calls
    might_sleep() in the pagefault handler, we get the following warning:

    BUG: sleeping function called from invalid context at ../arch/x86/mm/fault.c:1187
    in_atomic(): 0, irqs_disabled(): 0, pid: 4706, name: bash
    Preemption disabled at:[<ffffffff81484339>] printk+0x48/0x4a

    To fix this, we release the RCU read lock before we crash.

    Tested this patch on linux 3.18 by booting off one of our boards.
---
 drivers/tty/sysrq.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 06ed20dd01ba..d779a51499a0 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -134,17 +134,10 @@ static struct sysrq_key_op sysrq_unraw_op = {
 
 static void sysrq_handle_crash(int key)
 {
-	char *killer = NULL;
-
-	/* we need to release the RCU read lock here,
-	 * otherwise we get an annoying
-	 * 'BUG: sleeping function called from invalid context'
-	 * complaint from the kernel before the panic.
-	 */
+	/* release the RCU read lock before crashing */
 	rcu_read_unlock();
-	panic_on_oops = 1;	/* force panic */
-	wmb();
-	*killer = 1;
+
+	panic("sysrq triggered crash\n");
 }
 static struct sysrq_key_op sysrq_crash_op = {
 	.handler	= sysrq_handle_crash,
-- 
2.19.0.397.gdd90340f6a-goog