From: Andrew Morton <akpm@linux-foundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
PaX Team <pageexec@freemail.hu>
Subject: Re: [PATCH v2] fix stack memory content leak via UNAME26
Date: Wed, 10 Oct 2012 15:46:37 -0700 [thread overview]
Message-ID: <20121010154637.5b201ed7.akpm@linux-foundation.org> (raw)
In-Reply-To: <CAGXu5jJCQ3RxoFJ5FrGo=FJLSApK2PKX0PAt=E8y=PECNn4XWg@mail.gmail.com>
On Wed, 10 Oct 2012 15:31:07 -0700
Kees Cook <keescook@chromium.org> wrote:
> > This looks unecessarily complicated. Is there a reason to be copying
> > all 65 bytes out to userspace?
> >
> > If not, then couldn't we just do
> >
> > len = scnprintf(...);
> > ret = copy_to_user(..., len + 1);
> >
> > ?
>
> As it is, nothing calls override_release with crazy "len" values, but,
> to make the code less fragile, there should be checking for
> sizeof(buf) vs len. In the patch I sent, bounding the sprintf was
> sizeof(buf), and the copy_to_user was bounded by effectively
> min(sizeof(buf), len). If you wanted to use scnprintf, you'd have to
> reorganize the checks and explicitly handle len == 0:
>
> if (!len)
> return -EFAULT;
> if (sizeof(buf) < len)
> len = sizeof(buf)
> len = scnprintf(buf, len, "2.6.%u%s", v, rest);
> ret = copy_to_user(release, buf, len + 1);
It would be pretty absurd for someone to call override_release() with
len==0? All callers use sizeof() on some pretty well-defined array.
So I'd have thought that something like
--- a/kernel/sys.c~a
+++ a/kernel/sys.c
@@ -1265,7 +1265,7 @@ DECLARE_RWSEM(uts_sem);
* Work around broken programs that cannot handle "Linux 3.0".
* Instead we map 3.x to 2.6.40+x, so e.g. 3.0 would be 2.6.40
*/
-static int override_release(char __user *release, int len)
+static int override_release(char __user *release, size_t len)
{
int ret = 0;
char buf[65];
@@ -1274,6 +1274,7 @@ static int override_release(char __user
char *rest = UTS_RELEASE;
int ndots = 0;
unsigned v;
+ size_t copy;
while (*rest) {
if (*rest == '.' && ++ndots >= 3)
@@ -1283,8 +1284,9 @@ static int override_release(char __user
rest++;
}
v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 40;
- snprintf(buf, len, "2.6.%u%s", v, rest);
- ret = copy_to_user(release, buf, len);
+ copy = scnprintf(buf, min(len, sizeof(buf)),
+ "2.6.%u%s", v, rest);
+ ret = copy_to_user(release, buf, copy + 1);
}
return ret;
}
would suffice?
Not a big deal I guess, but copying out stuff beyond the NUL is a bit odd.
next prev parent reply other threads:[~2012-10-10 22:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-09 22:54 [PATCH v2] fix stack memory content leak via UNAME26 Kees Cook
2012-10-10 20:46 ` Andrew Morton
2012-10-10 22:31 ` Kees Cook
2012-10-10 22:46 ` Andrew Morton [this message]
2012-10-10 23:36 ` Kees Cook
2012-10-10 23:44 ` Andrew Morton
2012-10-11 0:39 ` Kees Cook
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=20121010154637.5b201ed7.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ak@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pageexec@freemail.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox