[bug report] keys: request_key_auth payload use-after-free in keyctl_instantiate_key_common()

[Shaomin Chen]

Hi,

keyctl_instantiate_key_common() can use a stale request_key_auth payload after
the current request-key authorisation key has been revoked.

The relevant code pattern is:

	rka = instkey->payload.data[0];
	...
	copy_from_iter_full(payload, plen, from);   /* can fault and sleep */
	...
	get_instantiation_keyring(ringid, rka, &dest_keyring);
	key_instantiate_and_link(rka->target_key, payload, plen,
				 dest_keyring, instkey);

keyctl_instantiate_key_common() does not hold authkey->sem, an RCU read-side
critical section, or a reference to the request_key_auth payload across the
sleeping copy and later rka dereferences.

One race sequence is:

	Task A: request-key helper child        Task B: original request_key path
	-------------------------------        ---------------------------------
	assume request-key authority
	enter KEYCTL_INSTANTIATE_IOV
	rka = instkey->payload.data[0]
	block in copy_from_iter_full()
	                                      helper parent instantiates target key
	                                      helper returns to kernel
	                                      complete_request_key(authkey, 0)
	                                      key_revoke(authkey)
	                                      request_key_auth_revoke(authkey)
	                                      rcu_assign_keypointer(authkey, NULL)
	                                      call_rcu(&rka->rcu, ...)
	                                      request_key_auth_rcu_disposal()
	                                      free_request_key_auth(rka)
	resume from copy_from_iter_full()
	get_instantiation_keyring(..., rka, ...)
	key_instantiate_and_link(rka->target_key, ...)

I reproduced this on a current upstream v7.1-rc3 based tree,
HEAD ab5fce87a778c, with KASAN enabled:

	BUG: KASAN: slab-use-after-free in keyctl_instantiate_key_common+0x1dc/0x2a0
	Read of size 8
	Allocated by task:
	  request_key_auth_new+0xe0/0x4d0
	Freed by task:
	  key_revoke+0x62/0xc0
	  call_sbin_request_key+0x6cb/0x740

The reproducer uses a request-key helper that forks a second process with the
request-key authority.  The second process enters KEYCTL_INSTANTIATE_IOV and
blocks in copy_from_iter_full() on a user fault after rka has been loaded.  The
original helper then instantiates the target key and returns, which revokes the
auth key and queues the request_key_auth payload for RCU freeing.  When the
blocked instantiate path resumes, it dereferences the stale rka pointer.

I can provide the reproducer and a candidate patch.

Regards,
Shaomin Chen