From: William Kucharski <william.kucharski@oracle.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Kees Cook <keescook@chromium.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Thomas Gleixner <tglx@linutronix.de>,
"linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH v3 0/3] Assorted improvements to usercopy
Date: Mon, 13 Dec 2021 19:18:57 +0000 [thread overview]
Message-ID: <196BFB9E-9A72-48B1-863E-021DE0B162A7@oracle.com> (raw)
In-Reply-To: <20211213142703.3066590-1-willy@infradead.org>
I like these, but a quick question:
Since the usercopy_abort() calls are all because the offset exceeds the page
size, is there a reason why you don't specifically state that via the detail
parameter rather than just supply a NULL pointer?
Otherwise for the patch series:
Reviewed-by: William Kucharski <william.kucharski@oracle.com>
> On Dec 13, 2021, at 7:27 AM, Matthew Wilcox (Oracle) <willy@infradead.org> wrote:
>
> We must prohibit page boundary crossing for kmap() addresses.
> vmap() addresses are limited by the length of the mapping, and
> compound pages are limited by the size of the page.
>
> These should probably all have test cases?
>
> v3:
> - Remove a now-unused variable
> v2:
> - Prevent a NULL pointer dereference when a vmalloc-range pointer
> doesn't have an associated allocation (me)
> - Report better offsets than "0" (Kees)
>
>
> Matthew Wilcox (Oracle) (3):
> mm/usercopy: Check kmap addresses properly
> mm/usercopy: Detect vmalloc overruns
> mm/usercopy: Detect compound page overruns
>
> arch/x86/include/asm/highmem.h | 1 +
> include/linux/highmem-internal.h | 10 ++++++++
> mm/usercopy.c | 43 +++++++++++++++++++++++---------
> 3 files changed, 42 insertions(+), 12 deletions(-)
>
> --
> 2.33.0
next prev parent reply other threads:[~2021-12-13 19:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 14:27 [PATCH v3 0/3] Assorted improvements to usercopy Matthew Wilcox (Oracle)
2021-12-13 14:27 ` [PATCH v3 1/3] mm/usercopy: Check kmap addresses properly Matthew Wilcox (Oracle)
2021-12-13 14:27 ` [PATCH v3 2/3] mm/usercopy: Detect vmalloc overruns Matthew Wilcox (Oracle)
2021-12-13 14:27 ` [PATCH v3 3/3] mm/usercopy: Detect compound page overruns Matthew Wilcox (Oracle)
2021-12-13 20:52 ` Kees Cook
2021-12-13 23:44 ` Matthew Wilcox
2021-12-13 23:50 ` Kees Cook
2021-12-13 19:18 ` William Kucharski [this message]
2021-12-13 20:27 ` [PATCH v3 0/3] Assorted improvements to usercopy Matthew Wilcox
2021-12-13 20:47 ` Kees Cook
2021-12-13 20:53 ` William Kucharski
2021-12-13 21:16 ` Matthew Wilcox
2021-12-13 23:47 ` 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=196BFB9E-9A72-48B1-863E-021DE0B162A7@oracle.com \
--to=william.kucharski@oracle.com \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tglx@linutronix.de \
--cc=willy@infradead.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.