public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: "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: [patch 2/2] lib/string.c: strlcpy() might read too far
Date: Wed, 2 Apr 2014 11:47:31 +0300	[thread overview]
Message-ID: <20140402084731.GB6018@mwanda> (raw)
In-Reply-To: <20140401.161838.1562296825577866979.davem@davemloft.net>

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 strnlen() call is obviously a little bit slower than strlen() but I
have tested it and I think it's probably ok.

Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/lib/string.c b/lib/string.c
index 9b1f906..8074962 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -148,10 +148,10 @@ EXPORT_SYMBOL(strncpy);
  */
 size_t strlcpy(char *dest, const char *src, size_t size)
 {
-	size_t ret = strlen(src);
+	size_t ret = strnlen(src, size);
 
 	if (size) {
-		size_t len = (ret >= size) ? size - 1 : ret;
+		size_t len = (ret < size) ? ret : ret - 1;
 		memcpy(dest, src, len);
 		dest[len] = '\0';
 	}

  parent reply	other threads:[~2014-04-02  8:48 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           ` Dan Carpenter [this message]
2014-04-14 21:46             ` [patch 2/2] lib/string.c: strlcpy() might read too far Andrew Morton
2014-04-15 10:38               ` Dan Carpenter
2014-04-14 22:21             ` Dave Jones
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=20140402084731.GB6018@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --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