From: Kees Cook <keescook@chromium.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Ilya Dryomov <idryomov@gmail.com>,
Daniel Thompson <daniel.thompson@linaro.org>,
Jason Wessel <jason.wessel@windriver.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Richard Weinberger <richard.weinberger@gmail.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH] bug: Exclude non-BUG/WARN exceptions from report_bug()
Date: Sun, 25 Feb 2018 08:52:51 -0800 [thread overview]
Message-ID: <20180225165251.GA11764@beast> (raw)
Commit:
b8347c219649 ("x86/debug: Handle warnings before the notifier chain, to fix KGDB crash")
changed the ordering of fixups, and did not take into account the case of
x86 processing non-WARN() and non-BUG() exceptions. This would lead to
output of a false BUG line with no other information. In the case of
a refcount exception, it would be immediately followed by the refcount
WARN(), producing very strange double-"cut here":
lkdtm: attempting bad refcount_inc() overflow
------------[ cut here ]------------
Kernel BUG at 0000000065f29de5 [verbose debug info unavailable]
------------[ cut here ]------------
refcount_t overflow at lkdtm_REFCOUNT_INC_OVERFLOW+0x6b/0x90 in cat[3065], uid/euid: 0/0
WARNING: CPU: 0 PID: 3065 at kernel/panic.c:657 refcount_error_report+0x9a/0xa4
...
In the prior ordering, exceptions were searched first:
do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str,
...
if (fixup_exception(regs, trapnr))
return 0;
- if (fixup_bug(regs, trapnr))
- return 0;
-
As a result, fixup_bugs()'s is_valid_bugaddr() didn't take into account
needing to search the exception list first, since that had already
happened.
So, instead of searching the exception list twice (once in
is_valid_bugaddr() and then again in fixup_exception()), just add a
simple sanity check to report_bug() that will immediately bail out
if a BUG() (or WARN()) entry is not found.
Fixes: b8347c219649 ("x86/debug: Handle warnings before the notifier chain, to fix KGDB crash")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
lib/bug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/bug.c b/lib/bug.c
index c1b0fad31b10..551e4d405307 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -150,6 +150,8 @@ enum bug_trap_type report_bug(unsigned long bugaddr, struct pt_regs *regs)
return BUG_TRAP_TYPE_NONE;
bug = find_bug(bugaddr);
+ if (!bug)
+ return BUG_TRAP_TYPE_NONE;
file = NULL;
line = 0;
--
2.7.4
--
Kees Cook
Pixel Security
reply other threads:[~2018-02-25 16:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20180225165251.GA11764@beast \
--to=keescook@chromium.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=daniel.thompson@linaro.org \
--cc=idryomov@gmail.com \
--cc=jason.wessel@windriver.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=richard.weinberger@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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).