From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ingo Molnar <mingo@kernel.org>
Cc: Jann Horn <jannh@google.com>,
andriy.shevchenko@linux.intel.com,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
the arch/x86 maintainers <x86@kernel.org>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/mtrr: don't copy out-of-bounds data in mtrr_write
Date: Mon, 16 Jul 2018 03:26:01 +0100 [thread overview]
Message-ID: <20180716022600.GN30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180715220339.GA15435@gmail.com>
On Mon, Jul 16, 2018 at 12:03:39AM +0200, Ingo Molnar wrote:
>
> * Jann Horn <jannh@google.com> wrote:
>
> > - A malicious user can pass an arbitrary file to a setuid binary as
> > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> > be something normal, like a proper file or a pipe) then calls read(0,
> > <buf>, <len>), if the kernel disregards the length argument and writes
> > beyond the end of the buffer, it can corrupt adjacent userspace data,
> > potentially allowing a user to escalate their privileges; a write
> > handler is somewhat less interesting because it can probably (as in
> > this case) only leak out-of-bounds data from the caller, not corrupt
> > it, but it's still a concern in theory.
>
> BTW., a naive question: would it make sense to simply disallow 'special'
> fds to be passed to setuid binaries, and fix any user-space that breaks?
> (i.e. only allow regular files and pipes/sockets.)
*Ugh*
You do realize that there's a lot of magical mystery shite that looks like
regular files? And what's wrong with directories, BTW?
While we are at it, "passed" in which sense? Via SCM_RIGHTS? Those are
only get accepted if recepient explicitly asks for those - simple read()
or recv() will have them quietly discarded, special or not.
And if it's "inherit over execve()"... Your definition *will* break.
Instantly. Right as you try to run su or sudo, with stdin/stdout/stderr
all going to a character device. Terminal, that is.
Frankly, something like
copyin_limited(buf, len, kbuf, size)
and several similar helpers would be a lot more productive than open-coding
these checks over and over or trying to come up with definitions of "special"
that would work.
BTW, what's the point open-coding
if (sscanf(line, "base=%ull size=%ull type=%s", &base, &size, &type) != 3)
return -EINVAL;
if ((base & 0xfff) || (size & 0xfff))
return -EINVAL;
i = match_string(mtrr_strings, MTRR_NUM_TYPES, type);
if (i < 0)
return i;
as
if (strncmp(line, "base=", 5))
return -EINVAL;
base = simple_strtoull(line + 5, &ptr, 0);
ptr = skip_spaces(ptr);
if (strncmp(ptr, "size=", 5))
return -EINVAL;
size = simple_strtoull(ptr + 5, &ptr, 0);
if ((base & 0xfff) || (size & 0xfff))
return -EINVAL;
ptr = skip_spaces(ptr);
if (strncmp(ptr, "type=", 5))
return -EINVAL;
ptr = skip_spaces(ptr + 5);
i = match_string(mtrr_strings, MTRR_NUM_TYPES, ptr);
if (i < 0)
return i;
Saving the copying of 'type' (which we need since '%n' is declared useless)?
prev parent reply other threads:[~2018-07-16 2:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-06 21:50 [PATCH] x86/mtrr: don't copy out-of-bounds data in mtrr_write Jann Horn
2018-07-07 17:04 ` [tip:x86/urgent] x86/mtrr: Don't " tip-bot for Jann Horn
2018-07-09 6:52 ` [PATCH] x86/mtrr: don't " Andy Shevchenko
2018-07-09 7:41 ` Jann Horn
2018-07-09 8:20 ` Andy Shevchenko
2018-07-15 22:03 ` Ingo Molnar
2018-07-16 1:32 ` Jann Horn
2018-07-16 1:46 ` Linus Torvalds
2018-07-16 2:26 ` Al Viro [this message]
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=20180716022600.GN30522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=andriy.shevchenko@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.