From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DE191FF1DA for ; Sun, 12 Jul 2026 12:00:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783857635; cv=none; b=oY6ncu06uKLfsaS/tJIgWWwT7643mFlDeSuv4v8QdbApvc8uVBmLRqqT/GtjK9ylHN7UAZk2ZCDL8mPkRytMqsBcmUej6bveukvRWDOgAWvJjxqicJ74fsgWEuFRQSrIvRAPAlNWqgBjXVlnrNISW6WBlO9ZXlJ8mTWZljh53ZE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783857635; c=relaxed/simple; bh=cxVKD3lzyVgNNbIYe3thzqbCjWBtHm3tfGK2UPL8YrU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ILLexYmKZYK6n7EyuIW+Qy3P5hC3SkzQU+XQ5J0yUwbyHeSQa/+aqGf2HaG8xMVmFGgOOwxwuJxQoOWsbbAWEpEkOz2Np4yjDAx/vCOb0oc4fU6bWo+1J+H339zWkRGE7kK07E/GWNjQmOSiFeIAisJzf7Tmmhx2DP65lMxi6fg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=wnq/4E/Y; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="wnq/4E/Y" Date: Sun, 12 Jul 2026 20:00:19 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1783857630; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kwd2Hm1aeQSElHv9iBES7Olf7mP2g8VZIOWbrDqKMfE=; b=wnq/4E/Yz4q4SWFX7z7A07PSbNlosNAoawhV3qB2X3Ay3rP18dPq8rkPQkpaSjvwToSsYX /KQN1ffo5ZAelv06TSLfA8/kDD9AArLlh6ZiwjQpadsSuV06Ca1jHueGB+BMemTiS6QKcQ rfhY1xpVaY8G5SiC3AGZt3DuxUSIdJ8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Baoquan He To: Guangshuo Li Cc: Andrew Morton , Mike Rapoport , Pasha Tatashin , Pratyush Yadav , Dave Young , Coiby Xu , kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] crash_dump: release keyring reference at the correct time Message-ID: References: <20260704112509.3717884-1-lgs201920130244@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260704112509.3717884-1-lgs201920130244@gmail.com> X-Migadu-Flow: FLOW_OUT On 07/04/26 at 07:25pm, Guangshuo Li wrote: > restore_dm_crypt_keys_to_thread_keyring() gets a reference to the user > keyring before restoring the saved dm-crypt keys. > > The same keyring reference is then passed to add_key_to_keyring() for each > saved key, but add_key_to_keyring() drops that reference on every call. > This is only balanced when exactly one key is restored. With multiple > keys, the keyring reference is dropped too many times and may trigger a > refcount underflow or use-after-free. > > When more than five keys are restored, a refcount underflow/use-after-free > warning can be triggered. > > The early error paths after lookup_user_key() also return without dropping > the keyring reference. > > Keep ownership of the keyring reference in > restore_dm_crypt_keys_to_thread_keyring(), drop it once on all exit paths, > and make add_key_to_keyring() only use the reference without consuming it. > > Fixes: 62f17d9df692 ("crash_dump: retrieve dm crypt keys in kdump kernel") > Signed-off-by: Guangshuo Li > --- > v2: > - Mention the refcount underflow/use-after warning seen when restoring > more than five keys, as suggested by Coiby Xu. > - Order local variables in reverse Christmas tree style. > > kernel/crash_dump_dm_crypt.c | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) LGTM, Acked-by: Baoquan He > > diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c > index cb875ddb6ba6..c685497cd470 100644 > --- a/kernel/crash_dump_dm_crypt.c > +++ b/kernel/crash_dump_dm_crypt.c > @@ -81,7 +81,6 @@ static int add_key_to_keyring(struct dm_crypt_key *dm_key, > kexec_dprintk("Error when adding key"); > } > > - key_ref_put(keyring_ref); > return r; > } > > @@ -104,6 +103,7 @@ static int restore_dm_crypt_keys_to_thread_keyring(void) > struct dm_crypt_key *key; > size_t keys_header_size; > key_ref_t keyring_ref; > + int ret = 0; > u64 addr; > > /* find the target keyring (which must be writable) */ > @@ -118,7 +118,8 @@ static int restore_dm_crypt_keys_to_thread_keyring(void) > dm_crypt_keys_read((char *)&key_count, sizeof(key_count), &addr); > if (key_count > KEY_NUM_MAX) { > kexec_dprintk("Failed to read the number of dm-crypt keys\n"); > - return -1; > + ret = -1; > + goto out; > } > > kexec_dprintk("There are %u keys\n", key_count); > @@ -126,8 +127,10 @@ static int restore_dm_crypt_keys_to_thread_keyring(void) > > keys_header_size = get_keys_header_size(key_count); > keys_header = kzalloc(keys_header_size, GFP_KERNEL); > - if (!keys_header) > - return -ENOMEM; > + if (!keys_header) { > + ret = -ENOMEM; > + goto out; > + } > > dm_crypt_keys_read((char *)keys_header, keys_header_size, &addr); > > @@ -137,7 +140,9 @@ static int restore_dm_crypt_keys_to_thread_keyring(void) > add_key_to_keyring(key, keyring_ref); > } > > - return 0; > +out: > + key_ref_put(keyring_ref); > + return ret; > } > > static int read_key_from_user_keyring(struct dm_crypt_key *dm_key) > -- > 2.43.0 >