From: Daniel Axtens <dja@axtens.net>
To: kasan-dev@googlegroups.com, x86@kernel.org,
aryabinin@virtuozzo.com, glider@google.com, luto@kernel.org,
linux-kernel@vger.kernel.org
Cc: Daniel Axtens <dja@axtens.net>, Marco Elver <elver@google.com>
Subject: [PATCH] x86: panic when a kernel stack overflow is detected
Date: Mon, 29 Jul 2019 11:59:33 +1000 [thread overview]
Message-ID: <20190729015933.18049-1-dja@axtens.net> (raw)
Currently, when a kernel stack overflow is detected via VMAP_STACK,
the task is killed with die().
This isn't safe, because we don't know how that process has affected
kernel state. In particular, we don't know what locks have been taken.
For example, we can hit a case with lkdtm where a thread takes a
stack overflow in printk() after taking the logbuf_lock. In that case,
we deadlock when the kernel next does a printk.
Do not attempt to kill the process when a kernel stack overflow is
detected. The system state is unknown, the only safe thing to do is
panic(). (panic() also prints without taking locks so a useful debug
splat is printed even when logbuf_lock is held.)
Reported-by: Marco Elver <elver@google.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
arch/x86/kernel/traps.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 4bb0f8447112..bfb0ec667c09 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -301,13 +301,14 @@ __visible void __noreturn handle_stack_overflow(const char *message,
struct pt_regs *regs,
unsigned long fault_address)
{
- printk(KERN_EMERG "BUG: stack guard page was hit at %p (stack is %p..%p)\n",
- (void *)fault_address, current->stack,
- (char *)current->stack + THREAD_SIZE - 1);
- die(message, regs, 0);
+ /*
+ * It's not safe to kill the task, as it's in kernel space and
+ * might be holding important locks. Just panic.
+ */
- /* Be absolutely certain we don't return. */
- panic("%s", message);
+ panic("%s - stack guard page was hit at %p (stack is %p..%p)",
+ message, (void *)fault_address, current->stack,
+ (char *)current->stack + THREAD_SIZE - 1);
}
#endif
--
2.20.1
next reply other threads:[~2019-07-29 1:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 1:59 Daniel Axtens [this message]
2019-07-29 3:53 ` [PATCH] x86: panic when a kernel stack overflow is detected Andy Lutomirski
2019-07-29 10:34 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190729015933.18049-1-dja@axtens.net \
--to=dja@axtens.net \
--cc=aryabinin@virtuozzo.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).