From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7408C288AD for ; Fri, 8 May 2026 13:15:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778246130; cv=none; b=o4kvT+Qz46YDw58/P22QHNWD/mJxh3facCe0StLjRKaNr3wCQQOPYIwzmtsVuDbka/gtTiu8iVFzKT52ebwDWTDug87SvwhRnEPv9uisJYMTZIVZwkb5UM4+jZQgeIppveRUUEEwCWucpP8H/DK12ZUjt40sGHHlsrLqKlgHgDs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778246130; c=relaxed/simple; bh=bVAEw3BnfcxbQok4aPMTWswjToJI76dFEH8JcIw6MiE=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UHT0GWVGRn6YYypIv1BjMIXJL1GQ16y49oEQAhiN5+3fCA8kEq+uBHurX5m1GZzYBsyWWQO90fNFwSlVP7AX3J/hNEghU/sk9jhEONFAv8wNl8uiy4a/9U/mAgaobX5+18eLerfJui6vTPYsUBUNoRNwdwRlCEUMIcpegvWbqhA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=L16WQfrM; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="L16WQfrM" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2a7a9b8ed69so18376255ad.2 for ; Fri, 08 May 2026 06:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778246129; x=1778850929; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to; bh=TaNuSxrcULkdilLhsv0noZRaTWQoCQ38fAARlU5eCIA=; b=L16WQfrML6EoUYFQciN66V6tLYSUUszQpHBTsfPUksgh+6NQfwld+gfhE2SiLwtXwJ c9GeJIz/5ue9nZHLgMJ4MfRzmru5HF9cJwDP+cVmXJUGcIcJyIbLiVEXN5Iv2Csq13Cr 3q3Ng9b1LtBvK4c72CAtl5BLjZKL0G4tIpyAp5mIHR3Ut+XmkHImIfPh36Sflf6y2RVa tUwfm/eixNV20hBKiZcbxbfDVXTY09TAEDje+ZYxmHqJhcNWoDJTDHdaPIsHUPvGv50G opaHwTnm+FjKzIwwP/BaEIS52IxQdSKsST+Z5L7qvYji3x5snixxFtWnA7mpL71IkrtK xAMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778246129; x=1778850929; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TaNuSxrcULkdilLhsv0noZRaTWQoCQ38fAARlU5eCIA=; b=Mkg33g/k2NeKUJG9Kq+2voHHFdAfLwHZR2EakQboIoPEho06YHguDftz8jAUV26eLu wCWSdRFSabIUJ5yTHF3VH71UkQWbzYMLkx6SUjgdi8xu+Bf5RNoxQG/MPk5QmmjYjt5B BOhBBhRpRrMn1UPaDBb0Q82iD3tkwxqSVPkjIM2KjyLKzHHBSRndU+V6eUhrSZ4q0nzV WzFtzo2vhJqQXELg+806h14WzDjquKEsDx6fCRyQnaYqmuzBX4LcuIbKy7YgZ1RaHwsC Nyaw3NUbpw3ZGW+P09n0BGluKFnZjUdxKeowC1h3zLEvCdqlZk/wVnIvLr/g7NZnwt9W t06w== X-Forwarded-Encrypted: i=1; AFNElJ8OjjFw5ofaoPcI8YZHUVv3Tdckn8VzV2vmlwqQ7FLrSVdMEq/9Vsi4uMcrglNSIXhLFfyDk8gn5drsDaI=@vger.kernel.org X-Gm-Message-State: AOJu0Yxp6ZMAq3hVubAEvJBL36SvOjiyMF8tJI3bquvHkQNpTJaDjmH6 8trOkJrlVHnmPFfvVWioTsiFIAnHwiW1xbBCpw2vClQnAmFpB0fMHZCeO9age/a2s7hSQA== X-Gm-Gg: Acq92OHeiPqNvsBnAFMX3WTebEIDXnyWgu6FHzXS/GE9DYLbacSMHEBNBfmPcAtrHsB MvSjSC6FzZu3S4j+4Hc57zcGBZtatf2uLqz0imqd3KO3RAcKvKGla04S1rEcGpwlcAaNaS6ZND2 2Dz71YJ04e/3hCXQ31dN8bnWItS9a7y22o3KEf+phFBQyVYyWXbizB5CT5mYkK3g9aMBQSZT1BO sTbpqcyZXHAj7zuouIspsF6aIHTTH+lBdm/ipYytc2GSBffycEk32OcC03+0vicZF8yS+L/blix Ama9LAYvKgWqvrfHjg7iGYCEjXHhY4kO2NQ4tXCr0QP2bUsY6sTABISqFXPU9EVC2kNbdoRz+7Q 1oYF9M/ztSG+6aA5mKb9yTPvv2dEndVqVJL5rxLv15IliCUx408rBo1CnJtDrGZ5Es6NGXX40YE mHUBirfGjKk6XuUidt0tPtN1+v0LqAkA== X-Received: by 2002:a17:902:8641:b0:2ba:6ffa:bde0 with SMTP id d9443c01a7336-2ba79c20bb9mr101621615ad.19.1778246128725; Fri, 08 May 2026 06:15:28 -0700 (PDT) Received: from localhost ([121.237.249.41]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2baf1d409eesm21600515ad.32.2026.05.08.06.15.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 06:15:28 -0700 (PDT) From: Coiby Xu X-Google-Original-From: Coiby Xu Date: Fri, 8 May 2026 21:08:39 +0800 To: Sourabh Jain Cc: kexec@lists.infradead.org, Andrew Morton , Baoquan He , Dave Young , Mike Rapoport , Pasha Tatashin , Pratyush Yadav , Coiby Xu , open list Subject: Re: [PATCH v2 3/9] crash_dump: Disallow writing to dm-crypt configfs during kexec_file_load syscall Message-ID: References: <20260501234342.2518281-1-coiby.xu@gmail.com> <20260501234342.2518281-4-coiby.xu@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=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, May 06, 2026 at 07:26:16PM +0530, Sourabh Jain wrote: > > >On 02/05/26 05:13, Coiby Xu wrote: >>If writing to the configfs group happens concurrently during >>kexec_file_load syscall, it may lead to the following issues, >> - buffer overflow if dm-crypt keys are added after allocation >> - stale total_keys if dm-crypt keys are removed during iteration >> - keys_header will not be freed if config/crash_dm_crypt_key/reuse is >> set true >> >>So hold config_keys_subsys.su_mutex for the entire sequence during the >>kexec_file_load syscall to ensure a consistent snapshot. > > >Yes, this will solve many synchronization problems when a  user tries to >perform any operation under our configfs_subsystem while the kernel is >executing the kexec_file_load system call. > >Now, regarding the third point about freeing key_header: this will work >only if configfs takes the su_mutex lock before invoking the store callback. >I am not sure whether it actually does. I can confirm configfs will automatically acquire the su_mutex lock when creating configfs item. But I forgot to try if writing to an item will also acquire the mutux lock. I'll do an experiment and share the result later. > >However, based on my previous comment on (2/9), if we keep >config_keys_reuse_store() >under the kexec lock, this will be taken care of. This is because the entire >kexec_file_load system call already runs under the kexec lock. > > >> >>Fixes: 479e58549b0f ("crash_dump: store dm crypt keys in kdump reserved memory") >>Signed-off-by: Coiby Xu >>--- >> kernel/crash_dump_dm_crypt.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >>diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c >>index 4d8a3331bbe7..6377ee86ec50 100644 >>--- a/kernel/crash_dump_dm_crypt.c >>+++ b/kernel/crash_dump_dm_crypt.c >>@@ -429,6 +429,7 @@ int crash_load_dm_crypt_keys(struct kimage *image) >> }; >> int r = 0; >>+ mutex_lock(&config_keys_subsys.su_mutex); >> if (key_count <= 0) { >> kexec_dprintk("No dm-crypt keys\n"); >>@@ -479,6 +480,9 @@ void kexec_file_post_load_cleanup_dm_crypt(struct kimage *image) >> kfree_sensitive(keys_header); >> keys_header = NULL; >> } >>+ >>+ if (mutex_is_locked(&config_keys_subsys.su_mutex)) >>+ mutex_unlock(&config_keys_subsys.su_mutex); >How about release the lock in crash_load_dm_crypt_keys() itself? Given >that config_keys_reuse_store() is placed under kexec lock? Thanks for proposing another solution! I'll give a try and make a comparison. -- Best regards, Coiby