From: Rik van Riel <riel@surriel.com>
To: Eric Biggers <ebiggers@kernel.org>, Kees Cook <keescook@chromium.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-security-module <linux-security-module@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Laura Abbott <labbott@redhat.com>
Subject: Re: crypto: Kernel memory overwrite attempt detected to spans multiple pages
Date: Wed, 10 Apr 2019 21:37:41 -0400 [thread overview]
Message-ID: <e3efd9c01626aa3bed02f10f845533711864bb17.camel@surriel.com> (raw)
In-Reply-To: <20190410231156.GB120258@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On Wed, 2019-04-10 at 16:11 -0700, Eric Biggers wrote:
> You've explained *what* it does again, but not *why*. *Why* do you
> want
> hardened usercopy to detect copies across page boundaries, when there
> is no
> actual buffer overflow?
When some subsystem in the kernel allocates multiple
pages without _GFP_COMP, there is no way afterwards
to detect exactly how many pages it allocated.
In other words, there is no way to see how large the
buffer is, nor whether the copy operation in question
would overflow it.
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2019-04-11 1:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-19 11:54 Geert Uytterhoeven
2019-03-19 17:09 ` Eric Biggers
2019-03-20 18:57 ` Eric Biggers
2019-03-21 17:45 ` Kees Cook
2019-03-21 17:51 ` Eric Biggers
2019-04-10 3:17 ` Eric Biggers
2019-04-10 18:30 ` Kees Cook
2019-04-10 19:07 ` Eric Biggers
2019-04-10 21:57 ` Kees Cook
2019-04-10 23:11 ` Eric Biggers
2019-04-10 23:27 ` Kees Cook
2019-04-11 17:58 ` Eric Biggers
2019-04-11 18:33 ` Kees Cook
2019-04-11 19:26 ` Eric Biggers
2019-04-11 19:28 ` [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP Eric Biggers
2019-04-11 20:32 ` Kees Cook
2019-04-12 5:38 ` Dmitry Vyukov
2019-04-15 2:24 ` Matthew Wilcox
2019-04-15 2:46 ` Herbert Xu
2019-04-16 2:18 ` Matthew Wilcox
2019-04-16 3:14 ` Kees Cook
2019-04-17 4:08 ` Matthew Wilcox
2019-04-17 8:09 ` Russell King - ARM Linux admin
2019-04-17 9:54 ` Robin Murphy
2019-04-11 20:36 ` crypto: Kernel memory overwrite attempt detected to spans multiple pages Kees Cook
2019-04-11 20:56 ` Eric Biggers
2019-04-11 1:37 ` Rik van Riel [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=e3efd9c01626aa3bed02f10f845533711864bb17.camel@surriel.com \
--to=riel@surriel.com \
--cc=ebiggers@kernel.org \
--cc=geert@linux-m68k.org \
--cc=herbert@gondor.apana.org.au \
--cc=keescook@chromium.org \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®