KEYS: asymmetric: reject non-positive restriction keys

asymmetric_lookup_restriction() resolves the serial in a key_or_keyring restriction with key_lookup(). This can return a negative or uninstantiated key as well as a positive one, and the restriction then retains that key.

When the key has the asymmetric type, key_or_keyring_common() treats it as a usable trust key and dereferences asymmetric_key_ids(trusted). Negative asymmetric keys have no payload, so linking an asymmetric key to the restricted keyring causes a NULL pointer dereference.

A process can retain a negative asymmetric key after a request_key() upcall fails and use its serial to restrict a keyring it owns. Linking a valid X.509 key to that keyring then triggers the fault without special privileges. On systems configured to panic on oops, this is a local denial of service.

KASAN reports:

  KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
  RIP: 0010:key_or_keyring_common+0x688/0x880
  Call Trace:
   key_link+0x1e1/0x300
   keyctl_keyring_link+0x6e/0xc0
   __do_sys_keyctl+0x299/0x530

Reject keys that have not been positively instantiated before installing the restriction. The explicit NULL trust key used by key_or_keyring:0:chain remains unaffected.

---
 crypto/asymmetric_keys/asymmetric_type.c | 5 +++++
 1 file changed, 5 insertions(+)

index 16a7ae16593c9e..ce78dbc8b8c1cc 100644
@@ -553,6 +553,11 @@ static struct key_restriction *asymmetric_lookup_restriction(
 				ret = ERR_CAST(key);
 				goto out;
 			}
+			if (!key_is_positive(key)) {
+				key_put(key);
+				ret = ERR_PTR(-ENOKEY);
+				goto out;
+			}
 		}
 
 		ret = asymmetric_restriction_alloc(link_fn, key);

base-commit: 3d6d817622b0a9721e3cc404df3469171582be13

2.54.0