public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Andi Kleen <ak@linux.intel.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Vegard Nossum <vegard.nossum@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch 2/2] lib/string.c: strlcpy() might read too far
Date: Mon, 14 Apr 2014 18:21:08 -0400	[thread overview]
Message-ID: <20140414222108.GA28206@redhat.com> (raw)
In-Reply-To: <20140402084731.GB6018@mwanda>

On Wed, Apr 02, 2014 at 11:47:31AM +0300, Dan Carpenter wrote:
 > Imagine you have a user controlled variable at the end of a struct which
 > is allocated at the end of a page.  The strlen() could read beyond the
 > mapped memory and cause an oops.
 > 
 > Probably there are two reasons why we have never hit this condition in
 > real life.  First you would have to be really unlucky for all the
 > variables to line up so the oops can happen.  Second we don't do a lot
 > of fuzzing with invalid strings.

The latter isn't necessarily true, trinity does pass all kinds of
garbage, including malformed ascii of various lengths. But what it
doesn't do fully is pass pointers to this junk in every struct we have
in the kernel. (Just the ones it knows about, which for now is mostly
things like sockaddr_t).

Do you have an example struct with layout like you describe ?
It probably wouldn't be much work to teach the fuzzer about it.
(The tricky part is getting such a malformed struct past the validation
 various syscalls do).

	Dave

  parent reply	other threads:[~2014-04-14 22:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01 10:08 [PATCH] isdnloop: NUL-terminate strings from userspace Vegard Nossum
2014-04-01 10:30 ` Hannes Frederic Sowa
2014-04-01 10:46   ` Vegard Nossum
2014-04-01 11:02     ` Hannes Frederic Sowa
2014-04-01 12:35       ` Dan Carpenter
2014-04-01 20:18         ` David Miller
2014-04-02  3:48           ` [PATCH] isdnloop: Validate NUL-terminated strings from user YOSHIFUJI Hideaki
2014-04-03 15:27             ` David Miller
2014-04-02  8:47           ` [patch 1/2] lib/string.c: use the name "C-string" in comments Dan Carpenter
2014-04-02  8:47           ` [patch 2/2] lib/string.c: strlcpy() might read too far Dan Carpenter
2014-04-14 21:46             ` Andrew Morton
2014-04-15 10:38               ` Dan Carpenter
2014-04-14 22:21             ` Dave Jones [this message]
2014-04-01 11:23 ` [PATCH] isdnloop: NUL-terminate strings from userspace YOSHIFUJI Hideaki

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=20140414222108.GA28206@redhat.com \
    --to=davej@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@oracle.com \
    --cc=hpa@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vegard.nossum@gmail.com \
    /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