Upstream 363b02dab09b3226 ("KEYS: Fix race between updating and finding a negative key"). Fixed in chromeos-4.4 with merge of v4.4.96. Needed in stable trees and older kernels.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/034f6f0ffe38113d6a68b5b7185eaf499732e441

commit 034f6f0ffe38113d6a68b5b7185eaf499732e441
Author: Eric Biggers <ebiggers@google.com>
Date: Wed Nov 15 18:17:47 2017

UPSTREAM: KEYS: prevent creating a different user's keyrings

[ Upstream commit 539255aea88e47932a98ba7656775cbca4f3d27c ]

commit 237bbd29f7a049d310d907f4b2716a7feef9abf3 upstream.

It was possible for an unprivileged user to create the user and user
session keyrings for another user.  For example:

    sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 "" @u
                           keyctl add keyring _uid_ses.4000 "" @u
                           sleep 15' &
    sleep 1
    sudo -u '#4000' keyctl describe @u
    sudo -u '#4000' keyctl describe @us

This is problematic because these "fake" keyrings won't have the right
permissions.  In particular, the user who created them first will own
them and will have full access to them via the possessor permissions,
which can be used to compromise the security of a user's keys:

    -4: alswrv-----v------------  3000     0 keyring: _uid.4000
    -5: alswrv-----v------------  3000     0 keyring: _uid_ses.4000

Fix it by marking user and user session keyrings with a flag
KEY_FLAG_UID_KEYRING.  Then, when searching for a user or user session
keyring by name, skip all keyrings that don't have the flag set.

BUG= chromium:784808 
BUG=b:69289864
TEST=Trybot on lakitu-pre-cq

Change-Id: I1fbd0e64275e68c44f7d8766539800e8347c9313
Fixes: 69664cf16af4 ("keys: don't generate user and user session keyrings unless they're accessed")
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>
Signed-off-by: Pradeep Sawlani <sawlani@google.com>
Reviewed-on: https://chromium-review.googlesource.com/768473
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/034f6f0ffe38113d6a68b5b7185eaf499732e441/security/keys/internal.h
[modify] https://crrev.com/034f6f0ffe38113d6a68b5b7185eaf499732e441/security/keys/process_keys.c
[modify] https://crrev.com/034f6f0ffe38113d6a68b5b7185eaf499732e441/security/keys/keyring.c
[modify] https://crrev.com/034f6f0ffe38113d6a68b5b7185eaf499732e441/include/linux/key.h
[modify] https://crrev.com/034f6f0ffe38113d6a68b5b7185eaf499732e441/security/keys/key.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cc216dc3606ef6b8d31ab413719f8096dd4b5f75

commit cc216dc3606ef6b8d31ab413719f8096dd4b5f75
Author: David Howells <dhowells@redhat.com>
Date: Wed Nov 15 18:17:57 2017

UPSTREAM: KEYS: Fix race between updating and finding a negative key

[ Upstream commit 8a004caec12bf241e567e3640401256cc9bc2e45 ]
commit 363b02dab09b3226f3bd1420dad9c72b79a42a76 upstream.

Consolidate KEY_FLAG_INSTANTIATED, KEY_FLAG_NEGATIVE and the rejection
error into one field such that:

 (1) The instantiation state can be modified/read atomically.

 (2) The error can be accessed atomically with the state.

 (3) The error isn't stored unioned with the payload pointers.

This deals with the problem that the state is spread over three different
objects (two bits and a separate variable) and reading or updating them
atomically isn't practical, given that not only can uninstantiated keys
change into instantiated or rejected keys, but rejected keys can also turn
into instantiated keys - and someone accessing the key might not be using
any locking.

The main side effect of this problem is that what was held in the payload
may change, depending on the state.  For instance, you might observe the
key to be in the rejected state.  You then read the cached error, but if
the key semaphore wasn't locked, the key might've become instantiated
between the two reads - and you might now have something in hand that isn't
actually an error code.

The state is now KEY_IS_UNINSTANTIATED, KEY_IS_POSITIVE or a negative error
code if the key is negatively instantiated.  The key_is_instantiated()
function is replaced with key_is_positive() to avoid confusion as negative
keys are also 'instantiated'.

Additionally, barriering is included:

 (1) Order payload-set before state-set during instantiation.

 (2) Order state-read before payload-read when using the key.

Further separate barriering is necessary if RCU is being used to access the
payload content after reading the payload pointers.

BUG= chromium:784808 
BUG=b:69289864
TEST=Trybot on lakitu-pre-cq

Change-Id: Ibcf73c08f4553960d04df17f19b0091d678071c8
Fixes: 146aa8b1453b ("KEYS: Merge the type-specific data with the payload data")
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pradeep Sawlani <sawlani@google.com>
Reviewed-on: https://chromium-review.googlesource.com/768475
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/request_key_auth.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/encrypted-keys/encrypted.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/key.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/user_defined.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/keyring.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/request_key.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/process_keys.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/gc.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/big_key.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/net/dns_resolver/dns_key.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/trusted.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/proc.c
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/include/linux/key.h
[modify] https://crrev.com/cc216dc3606ef6b8d31ab413719f8096dd4b5f75/security/keys/keyctl.c

Does this need to go into M63?

It is in chromeos-4.4 / M63 (through  crbug.com/781520 ). I'd rather keep it out of older R63 kernels due to the large number context changes; I recently applied some 18 KEYS related changes to chromeos-3.18, with more to go, and this is a bit too much for a stable release. I won't even try to apply the series to older kernels. So I think we can call this fixed.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot