linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Masami Hiramatsu <mhiramat@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration
Date: Sun, 23 Apr 2017 17:41:11 +0000	[thread overview]
Message-ID: <1492968472.gwfhge4zw5.astroid@naverao1-tp.none> (raw)
In-Reply-To: <87inlxyoja.fsf@concordia.ellerman.id.au>

Excerpts from Michael Ellerman's message of April 22, 2017 11:25:
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> 
>> When a kprobe is being registered, we use the symbol_name field to
>> lookup the address where the probe should be placed. Since this is a
>> user-provided field, let's ensure that the length of the string is
>> within expected limits.
> 
> What are we actually trying to protect against here?
> 
> If you ignore powerpc for a moment, kprobe_lookup_name() is just
> kallsyms_lookup_name().
> 
> All kallsyms_lookup_name() does with name is strcmp() it against a
> legitimate symbol name which is at most KSYM_NAME_LEN.
> 
> So I don't think any of this validation helps in that case?

It does:
https://patchwork.kernel.org/patch/9695139/

It is far too easy to cause a OOPS due to the above, though this is 
root-only (for modules).

As I stated earlier, I think it is always a good practice to validate 
inputs right on entry, rather than later. Code gets refactored, 
different arch support gets added, and so on.

Doing this validation here ensures we don't have to worry about how we 
process this later, or if another arch has to over-ride 
kprobe_lookup_name().

> 
> In the powerpc version of kprobe_lookup_name() we do need to do some
> string juggling, for which it helps to know the input is sane. But I
> think we should just make that code more robust by checking the input
> before we do anything with it.

Ok, I will fold those tests in with the powerpc implementation for now 
and consider a patch against kallsyms_lookup_name(), like Masami 
recommends.


- Naveen

  reply	other threads:[~2017-04-23 17:42 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19 12:50 [PATCH v3 0/7] powerpc: a few kprobe fixes and refactoring Naveen N. Rao
2017-04-19 12:51 ` [PATCH v3 1/7] kprobes: convert kprobe_lookup_name() to a function Naveen N. Rao
2017-04-24 22:47   ` [v3,1/7] " Michael Ellerman
2017-04-19 12:51 ` [PATCH v3 2/7] powerpc: kprobes: fix handling of function offsets on ABIv2 Naveen N. Rao
2017-04-24 22:47   ` [v3,2/7] " Michael Ellerman
2017-04-19 12:51 ` [PATCH v3 3/7] kprobes: validate the symbol name length Naveen N. Rao
2017-04-19 14:37   ` Masami Hiramatsu
2017-04-19 16:38     ` Naveen N. Rao
2017-04-21 13:42       ` Masami Hiramatsu
2017-04-23 15:44         ` Naveen N. Rao
2017-04-25  3:18           ` Masami Hiramatsu
2017-04-20  6:08   ` Michael Ellerman
2017-04-20  7:19     ` Naveen N. Rao
2017-04-21 12:32   ` [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration Naveen N. Rao
2017-04-21 13:11     ` Paul Clarke
2017-04-21 13:25       ` Naveen N. Rao
2017-04-21 13:54     ` Masami Hiramatsu
2017-04-22  5:55     ` Michael Ellerman
2017-04-23 17:41       ` Naveen N. Rao [this message]
2017-04-21 12:33   ` [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name() Naveen N. Rao
2017-04-21 13:33     ` Paul Clarke
2017-04-21 13:36       ` Paul Clarke
2017-04-21 13:52       ` Paul Clarke
2017-04-23 17:09         ` Naveen N. Rao
2017-04-19 12:51 ` [PATCH v3 4/7] powerpc: kprobes: use " Naveen N. Rao
2017-04-21 15:06   ` David Laight
2017-04-19 12:51 ` [PATCH v3 5/7] powerpc: kprobes: factor out code to emulate instruction into a helper Naveen N. Rao
2017-04-19 14:40   ` Masami Hiramatsu
2017-04-24 22:47   ` [v3, " Michael Ellerman
2017-04-19 12:51 ` [PATCH v3 6/7] powerpc: kprobes: emulate instructions on kprobe handler re-entry Naveen N. Rao
2017-04-19 14:43   ` Masami Hiramatsu
2017-04-19 16:42     ` Naveen N. Rao
2017-04-20  6:11       ` Michael Ellerman
2017-04-21 13:48         ` Masami Hiramatsu
2017-04-24 22:47   ` [v3, " Michael Ellerman
2017-04-19 12:51 ` [PATCH v3 7/7] powerpc: kprobes: remove duplicate saving of msr Naveen N. Rao
2017-04-19 14:43   ` Masami Hiramatsu
2017-04-23 11:53   ` [v3,7/7] " Michael Ellerman

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=1492968472.gwfhge4zw5.astroid@naverao1-tp.none \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    /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).