From: James Morris <jmorris@namei.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Howells <dhowells@redhat.com>,
Eric Biggers <ebiggers@google.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: [GIT PULL] security: keys fixes for v4.14-rc3
Date: Fri, 29 Sep 2017 08:33:13 +1000 (AEST) [thread overview]
Message-ID: <alpine.LRH.2.21.1709290822590.15742@namei.org> (raw)
Hi Linus,
Please pull these fixes for the keys subsystem.
Notable here is a rewrite of big_key crypto by Jason Donenfeld to address
some issues in the original code.
>From Jason's commit log:
"This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot
time. But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws."
There has been positive review of the new code by Eric Biggers and Herbert
Xu, and it passes basic testing via the keyutils test suite. Eric also
manually tested it.
Generally speaking, we likely need to improve the amount of crypto review
for kernel crypto users including keys (I'll post a note separately to
ksummit-discuss).
---
The following changes since commit 9cd6681cb1169e815c41af0265165dd1b872f228:
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs (2017-09-27 12:22:12 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git fixes-v4.14-rc3
Eric Biggers (10):
KEYS: fix cred refcount leak in request_key_auth_new()
KEYS: don't revoke uninstantiated key in request_key_auth_new()
KEYS: fix key refcount leak in keyctl_assume_authority()
KEYS: fix key refcount leak in keyctl_read_key()
KEYS: fix writing past end of user-supplied buffer in keyring_read()
KEYS: prevent creating a different user's keyrings
KEYS: prevent KEYCTL_READ on negative key
KEYS: reset parent each time before searching key_user_tree
KEYS: restrict /proc/keys by credentials at open time
KEYS: use kmemdup() in request_key_auth_new()
James Morris (1):
Merge commit 'keys-fixes-20170927' into fixes-v4.14-rc3
Jason A. Donenfeld (2):
security/keys: properly zero out sensitive key material in big_key
security/keys: rewrite all of big_key crypto
include/linux/key.h | 2 +
security/keys/Kconfig | 4 +-
security/keys/big_key.c | 139 ++++++++++++++++++--------------------
security/keys/internal.h | 2 +-
security/keys/key.c | 6 +-
security/keys/keyctl.c | 13 ++--
security/keys/keyring.c | 37 +++++-----
security/keys/proc.c | 8 +--
security/keys/process_keys.c | 6 +-
security/keys/request_key_auth.c | 74 +++++++++-----------
10 files changed, 139 insertions(+), 152 deletions(-)
next reply other threads:[~2017-09-28 22:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 22:33 James Morris [this message]
2017-09-28 22:39 ` Jason A. Donenfeld
2017-09-28 22:53 ` James Morris
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=alpine.LRH.2.21.1709290822590.15742@namei.org \
--to=jmorris@namei.org \
--cc=Jason@zx2c4.com \
--cc=dhowells@redhat.com \
--cc=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=torvalds@linux-foundation.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®