https://source.android.com/security/bulletin/2018-02-01
CVE-2017-16939
CVE-2017-17558
CVE-2017-1000405
CVE-2017-15265
CVE-2015-9016
CVE-2017-17807

Cherry-picked these patches from android-3.18 to fix 'allconfigs'
build-breaks, they are not cited in the ASB:

168ef6174500 ANDROID: dm verity: Export dm_disk
fb7c652ca8f7 UPSTREAM: init: export name_to_dev_t and mark name argument as const
06ed0c85f4e4 UPSTREAM: sched: Export sched_setscheduler_nocheck
1954cf568b14 ANDROID: Skip building uid_sys_stats and keyreset drivers as modules
8859b2e134db video: adf: Set ADF_MEMBLOCK to boolean
bbaaa3335b7d video: adf: Fix modular build
80ffc32d22a1 ANDROID: fs: Export vfs_rmdir2
28a6fe41d28e ANDROID: fs: Export free_fs_struct and set_fs_pwd
4ab19b012831 ANDROID: export security_path_chown
417b332ff7d4 mm: Export do_munmap
d78915f8f5b8 Revert "net: socket ioctl to reset connections matching local address"
a2a9f19f10f1 Revert "net: tcp: fix rtable leak in tcp_is_local[6]"
13cac8f18d7b Revert "net: fix iterating over hashtable in tcp_nuke_addr()"
2ba8a99ee9ee Revert "net: fix crash in tcp_nuke_addr()"
76162bb829cd Revert "Don't kill IPv4 sockets when killing IPv6 sockets was requested."
deb43fbeed7b UPSTREAM: usb: gadget: midi: convert to new interface of f_midi
KEYS: add missing permission check for request_key() destination

commit 4dca6ea1d9432052afb06baf2e3ae78188a4410b upstream.

When the request_key() syscall is not passed a destination keyring, it
links the requested key (if constructed) into the "default" request-key
keyring.  This should require Write permission to the keyring.  However,
there is actually no permission check.

This can be abused to add keys to any keyring to which only Search
permission is granted.  This is because Search permission allows joining
the keyring.  keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING)
then will set the default request-key keyring to the session keyring.
Then, request_key() can be used to add keys to the keyring.

Both negatively and positively instantiated keys can be added using this
method.  Adding negative keys is trivial.  Adding a positive key is a
bit trickier.  It requires that either /sbin/request-key positively
instantiates the key, or that another thread adds the key to the process
keyring at just the right time, such that request_key() misses it
initially but then finds it in construct_alloc_key().

Fix this bug by checking for Write permission to the keyring in
construct_get_dest_keyring() when the default keyring is being used.

We don't do the permission check for non-default keyrings because that
was already done by the earlier call to lookup_user_key().  Also,
request_key_and_link() is currently passed a 'struct key *' rather than
a key_ref_t, so the "possessed" bit is unavailable.

We also don't do the permission check for the "requestor keyring", to
continue to support the use case described by commit 8bbf4976b59f
("KEYS: Alter use of key instantiation link-to-keyring argument") where
/sbin/request-key recursively calls request_key() to add keys to the
original requestor's destination keyring.  (I don't know of any users
who actually do that, though...)

Fixes: 3e30148c3d52 ("[PATCH] Keys: Make request-key create an authorisation key")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

1 file changed