From: Rik van Riel <riel@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: kernel-hardening@lists.openwall.com,
Brad Spengler <spender@grsecurity.net>,
PaX Team <pageexec@freemail.hu>,
Casey Schaufler <casey.schaufler@intel.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [kernel-hardening] Re: [PATCH v2 2/4] usercopy: avoid direct copying to userspace
Date: Thu, 9 Jun 2016 19:37:14 -0400 [thread overview]
Message-ID: <20160609193714.0f302022@annuminas.surriel.com> (raw)
In-Reply-To: <1465420302-23754-3-git-send-email-keescook@chromium.org>
On Wed, 8 Jun 2016 14:11:40 -0700
Kees Cook <keescook@chromium.org> wrote:
> Some non-whitelisted heap memory has small areas that need to be copied
> to userspace. For these cases, explicitly copy the needed contents out
> to stack first before sending to userspace. This lets their respective
> caches remain un-whitelisted (i.e. no SLAB_USERCOPY), since the bulk of
> their contents should not be exposed to userspace.
>
> These changes, based on code by Brad Spengler and PaX Team, were extracted
> from grsecurity/PaX on a case-by-case basis as I ran into errors during
> testing of CONFIG_HARDENED_USERCOPY_WHITELIST:
You will want this bit as well. It is an adaptation, with
a slight change after digging through XFS code for an hour
and a half or so, of code originally from grsecurity.
With this change, my system boots a usercopy kernel without
any visible issues.
---8<---
Subject: mm,xfs: bounce buffer the file name in xfs_dir2_sf_getdents
"Short form" directories in XFS have the directory content inside the
in-memory inode, or other kernel memory. The directory contents can be
in the same slab object as other, more sensitive, contents.
Instead of marking the xfs_inode slab accessible to copy_from_user and
copy_to_user, bounce buffer the file name when doing getdents on a short
form directory.
This only affects short form directories, which will have a very small
number of entries. Large directories use different code.
Adapted from the grsecurity patch set. Thanks go out to pipacs and spender.
Signed-off-by: Rik van Riel <riel@redhat.com>
---
fs/xfs/xfs_dir2_readdir.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_dir2_readdir.c b/fs/xfs/xfs_dir2_readdir.c
index f44f79996978..bc6c78cbe4c6 100644
--- a/fs/xfs/xfs_dir2_readdir.c
+++ b/fs/xfs/xfs_dir2_readdir.c
@@ -127,6 +127,7 @@ xfs_dir2_sf_getdents(
*/
sfep = xfs_dir2_sf_firstentry(sfp);
for (i = 0; i < sfp->count; i++) {
+ char name[sfep->namelen];
__uint8_t filetype;
off = xfs_dir2_db_off_to_dataptr(geo, geo->datablk,
@@ -140,7 +141,14 @@ xfs_dir2_sf_getdents(
ino = dp->d_ops->sf_get_ino(sfp, sfep);
filetype = dp->d_ops->sf_get_ftype(sfep);
ctx->pos = off & 0x7fffffff;
- if (!dir_emit(ctx, (char *)sfep->name, sfep->namelen, ino,
+ /*
+ * Short form directories have the file name stored in
+ * memory that is not directly accessible to copy_to_user.
+ * Bounce buffer the name, instead of potentially making
+ * the other data accessible.
+ */
+ memcpy(name, sfep->name, sfep->namelen);
+ if (!dir_emit(ctx, name, sfep->namelen, ino,
xfs_dir3_get_dtype(dp->i_mount, filetype)))
return 0;
sfep = dp->d_ops->sf_nextentry(sfp, sfep);
next prev parent reply other threads:[~2016-06-09 23:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 21:11 [kernel-hardening] [RFC][PATCH v2 0/4] mm: Hardened usercopy Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 1/4] " Kees Cook
2016-06-09 0:47 ` [kernel-hardening] " Brad Spengler
2016-06-09 1:39 ` Rik van Riel
2016-06-09 2:58 ` Kees Cook
2016-07-12 23:04 ` Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 2/4] usercopy: avoid direct copying to userspace Kees Cook
2016-06-09 23:37 ` Rik van Riel [this message]
2016-06-10 21:09 ` [kernel-hardening] " Kees Cook
2016-06-11 1:08 ` Rik van Riel
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 3/4] usercopy: whitelist user-copyable caches Kees Cook
2016-06-08 21:11 ` [kernel-hardening] [PATCH v2 4/4] usercopy: provide split of user-controlled slabs Kees Cook
2016-06-09 3:02 ` [kernel-hardening] [RFC][PATCH v2 5/4] arm: fixes for usercopy Kees Cook
2016-06-09 15:35 ` [kernel-hardening] RE: [RFC][PATCH v2 0/4] mm: Hardened usercopy Schaufler, Casey
2016-06-09 17:48 ` [kernel-hardening] " Kees Cook
2016-06-09 23:39 ` [kernel-hardening] [RFC][PATCH 6/4] mm: disallow user copy to/from separately allocated pages Rik van Riel
2016-06-10 19:44 ` [kernel-hardening] [RFC][PATCH v2 " Rik van Riel
2016-06-10 20:46 ` [kernel-hardening] " Kees Cook
2016-06-24 20:53 ` Kees Cook
2016-06-24 20:57 ` Rik van Riel
2016-06-24 20:59 ` Kees Cook
2016-06-16 1:30 ` [kernel-hardening] [RFC][PATCH v2 0/4] mm: Hardened usercopy Valdis.Kletnieks
2016-06-16 1:38 ` Kees Cook
2016-06-16 23:36 ` Valdis.Kletnieks
2016-06-17 1:38 ` Valdis.Kletnieks
2016-06-18 19:30 ` 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=20160609193714.0f302022@annuminas.surriel.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=casey.schaufler@intel.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=pageexec@freemail.hu \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=spender@grsecurity.net \
/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;
as well as URLs for NNTP newsgroup(s).