From: Ingo Molnar <mingo@kernel.org>
To: Jann Horn <jannh@google.com>
Cc: 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 00:03:39 +0200 [thread overview]
Message-ID: <20180715220339.GA15435@gmail.com> (raw)
In-Reply-To: <CAG48ez105Jan3BDAKssThnbNcr3yBMFTbdQHEHwXdmZUvE5VQw@mail.gmail.com>
* 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.)
Also, don't allow splice() on special files either, except if the driver
explicitly opts in to it.
Sounds a lot more robust in the long run than playing whack-a-mole with the
*inevitable* hole in special read() and write() handlers in our 3,000+ device
drivers...
Thanks,
Ingo
next prev parent reply other threads:[~2018-07-15 22:04 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 [this message]
2018-07-16 1:32 ` Jann Horn
2018-07-16 1:46 ` Linus Torvalds
2018-07-16 2:26 ` Al Viro
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=20180715220339.GA15435@gmail.com \
--to=mingo@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.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.