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

[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

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

[Jarkko Sakkinen]

On Tue, May 19, 2026 at 10:44:03PM +0800, Shaomin Chen wrote:
> 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

Please, just send them and we go from there. On surface looks legit.

BR, Jarkko