linux-kernel - [PATCH 0/3] [GIT PULL] tracing: some more fixes before my 4.2 pull request

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: <20150626150024.270253464@goodmis.org>
Date:	Fri, 26 Jun 2015 11:00:24 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	linux-kernel@...r.kernel.org
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH 0/3] [GIT PULL] tracing: some more fixes before my 4.2 pull request

Linus,

This isn't my 4.2 pull request (yet). I found a few more bugs that
I would have sent to fix 4.1, but since 4.1 is already out, I'm
sending this before sending my 4.2 request (which is ready to go).

After fixing the previous filter issue reported by Vince Weaver,
I could not come up with a situation where the operand counter (cnt)
could go below zero, so I added a WARN_ON_ONCE(cnt < 0). Vince was
able to trigger that warn on with his fuzzer test, but didn't have
a filter input that caused it.

Later, Sasha Levin was able to trigger that same warning, and was
able to give me the filter string that triggered it. It was simply
a single operation ">".

I wrapped the filtering code in a userspace program such that I could
single step through the logic. With a single operator the operand
counter can legitimately go below zero, and should be reported to the
user as an error, but should not produce a kernel warning. The
WARN_ON_ONCE(cnt < 0) should be just a "if (cnt < 0) break;" and the
code following it will produce the error message for the user.

While debugging this, I found that there was another bug that let
the pointer to the filter string go beyond the filter string.
This too was fixed.

Finally, there was a typo in a stub function that only gets compiled
if trace events is disabled but tracing is enabled (I'm not even sure
that's possible).

Please pull the latest trace-fixes-4.1 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-4.1

Tag SHA1: 518521eb203ca82fce34c3e496c2d31af30e1ef4
Head SHA1: cc9e4bde03f2b4cfba52406c021364cbd2a4a0f3

Steven Rostedt (Red Hat) (3):
      tracing/filter: Do not WARN on operand count going below zero
      tracing/filter: Do not allow infix to exceed end of string
      tracing: Fix typo from "static inlin" to "static inline"

----
 kernel/trace/trace.h               |  2 +-
 kernel/trace/trace_events_filter.c | 10 +++++++++-
 2 files changed, 10 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/