All of lore.kernel.org
 help / color / mirror / Atom feed
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.