Message ID | 20230802094931.18215-1-lhenriques@suse.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f41:0:b0:3e4:2afc:c1 with SMTP id v1csp373363vqx; Wed, 2 Aug 2023 04:09:07 -0700 (PDT) X-Google-Smtp-Source: APBJJlGIiGzMskgpvtcAzGI+E7wqNvv+JIazh4/PsKBvXb/tOAhQ8mF8cwts6FXlbrbE2jE4CyuV X-Received: by 2002:a05:6808:1413:b0:3a7:543b:b636 with SMTP id w19-20020a056808141300b003a7543bb636mr3622167oiv.16.1690974546976; Wed, 02 Aug 2023 04:09:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690974546; cv=none; d=google.com; s=arc-20160816; b=E2YlYyTPRBdB3zNrXwbJjND7ZPPb950UeLFeEx2pWUuHIqPqtuKCp++G7emPqZKsuo YVTGDqyh7dEAWmXkG77ds7Peap3jRHD2vcGQr6kabZxXvaPVyG906howUdEAOUUj5m98 PEPPLQ6/6XmD78Od5ZuxbcmxGgpH5gGVITLG7Q/MKhCw8SfS5s+5TWoPBov023Hcb6z+ A+SXSlbKsRBVRByVQmEKAdGmCkS5vx+tc6AAr4icVUL0cI6qIpRra7OeKgB8pHmJ0hDY bWV2iXbDppC4f6AJq9fwxXF0d/103ANLVxpUwXSI57GLtWbqrF39mgXboC7t8X6BaXxw Z+dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=oG99N9wn1Zwsv4UxpgLJDybTYUZ52WwqDECex34X2Ok=; fh=Podj8p+K1fkxTRmxRPx4mxr3QsttTSduPMq2N9o6PM8=; b=g5pHYnnTiKIqBq0J6SOHg+GurZvmHNi7qrpuedEdFxTYiTTzfWH0Z93RL4f3djtWI+ DzF0teOMUNVUnzBqSYiB02/LKifEmmrPVYk2S5B95lOGZ8zUr4TpRhNkfprWA4g791X6 CP891MMJzZVd0XdrbMfUyfL3ATyykJbqHwre4fNgYNCcEB4wqR7ebyTzY1tBZ3SJuPSM BnzI8hwenh0EGNr/l7fBysZMF9D0zjHse3KNuuiFtqxCq5hIuWAs73nZPX6mV7W24gD9 /D8wFarCvURwYzskTCpfwyHByGkLzRQ1kdRoXsdv5mLkEABgPKKHi3IvhqLzUl+MeN9I 22OA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=1jYsc+Xy; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k32-20020a634b60000000b00563540798f1si10336804pgl.342.2023.08.02.04.08.45; Wed, 02 Aug 2023 04:09:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=1jYsc+Xy; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232084AbjHBJtj (ORCPT <rfc822;maxi.paulin@gmail.com> + 99 others); Wed, 2 Aug 2023 05:49:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230396AbjHBJth (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 2 Aug 2023 05:49:37 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACF8FE57; Wed, 2 Aug 2023 02:49:36 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5F9C51F749; Wed, 2 Aug 2023 09:49:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1690969775; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=oG99N9wn1Zwsv4UxpgLJDybTYUZ52WwqDECex34X2Ok=; b=1jYsc+Xy79TkLiVn8FyhO/kCudhhFlmkevXic8bQl4pI+sEVJzTa3j5QpCtwOF4vWXNci5 ycr/pF6rZEggWoev1UZWk4lp8ZVcy7hRYujImA6kHsfHNkNMfUiGAiWdwMdtUiYjlW5374 JWL1c+dngQvLpEOHaydpH+yOrfT03j0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1690969775; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=oG99N9wn1Zwsv4UxpgLJDybTYUZ52WwqDECex34X2Ok=; b=53er0okG6zAS0kRbBncgS1qtXng3Y93tUmR9bxJXqjXIilpziX+PEA5fSnqfQ/b+DnPjcS ckvf68sWHKpFBACw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E48FB13909; Wed, 2 Aug 2023 09:49:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id fpPoNK4mymRycAAAMHmgww (envelope-from <lhenriques@suse.de>); Wed, 02 Aug 2023 09:49:34 +0000 Received: from localhost (brahms.olymp [local]) by brahms.olymp (OpenSMTPD) with ESMTPA id a355a2d3; Wed, 2 Aug 2023 09:49:34 +0000 (UTC) From: =?utf-8?q?Lu=C3=ADs_Henriques?= <lhenriques@suse.de> To: Theodore Ts'o <tytso@mit.edu>, Andreas Dilger <adilger.kernel@dilger.ca>, Daniel Rosenberg <drosen@google.com>, Eric Biggers <ebiggers@kernel.org> Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?Lu?= =?utf-8?q?=C3=ADs_Henriques?= <lhenriques@suse.de> Subject: [PATCH v2] ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} Date: Wed, 2 Aug 2023 10:49:31 +0100 Message-Id: <20230802094931.18215-1-lhenriques@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773115326499589084 X-GMAIL-MSGID: 1773115326499589084 |
Series |
[v2] ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}
|
|
Commit Message
Luis Henriques
Aug. 2, 2023, 9:49 a.m. UTC
If casefolding the filename fails, we'll be leaking fscrypt_buf name.
Make sure we free it in the error paths of ext4_fname_setup_filename() and
ext4_fname_prepare_lookup() functions.
Fixes: 1ae98e295fa2 ("ext4: optimize match for casefolded encrypted dirs")
Signed-off-by: Luís Henriques <lhenriques@suse.de>
---
Changes since v1:
- Include fix to ext4_fname_prepare_lookup() as well
- Add 'Fixes:' tag
fs/ext4/crypto.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
On Wed, Aug 02, 2023 at 10:49:31AM +0100, Luís Henriques wrote: > If casefolding the filename fails, we'll be leaking fscrypt_buf name. fscrypt_buf => fscrypt_name > diff --git a/fs/ext4/crypto.c b/fs/ext4/crypto.c > index e20ac0654b3f..3c05c7f3415b 100644 > --- a/fs/ext4/crypto.c > +++ b/fs/ext4/crypto.c > @@ -33,6 +33,8 @@ int ext4_fname_setup_filename(struct inode *dir, const struct qstr *iname, > struct fscrypt_name name; > int err; > > err = fscrypt_setup_filename(dir, iname, lookup, &name); > if (err) > return err; > > ext4_fname_from_fscrypt_name(fname, &name); > > #if IS_ENABLED(CONFIG_UNICODE) > err = ext4_fname_setup_ci_filename(dir, iname, fname); > + if (err) > + fscrypt_free_filename(&name); > #endif > return err; > } > @@ -51,6 +53,8 @@ int ext4_fname_prepare_lookup(struct inode *dir, struct dentry *dentry, > struct fscrypt_name name; > int err; > > err = fscrypt_prepare_lookup(dir, dentry, &name); > if (err) > return err; > > ext4_fname_from_fscrypt_name(fname, &name); > > #if IS_ENABLED(CONFIG_UNICODE) > err = ext4_fname_setup_ci_filename(dir, &dentry->d_name, fname); > + if (err) > + fscrypt_free_filename(&name); > #endif > return err; > } This works, but it's a bit weird that the freeing happens on the original struct fscrypt_name after it has already been "moved" to the struct ext4_filename by ext4_fname_from_fscrypt_name(). That leaves a dangling pointer in the struct ext4_filename. Maybe you should call ext4_fname_free_filename() instead, even though it would do some unnecessary work? - Eric
Eric Biggers <ebiggers@kernel.org> writes: > On Wed, Aug 02, 2023 at 10:49:31AM +0100, Luís Henriques wrote: >> If casefolding the filename fails, we'll be leaking fscrypt_buf name. > > fscrypt_buf => fscrypt_name > >> diff --git a/fs/ext4/crypto.c b/fs/ext4/crypto.c >> index e20ac0654b3f..3c05c7f3415b 100644 >> --- a/fs/ext4/crypto.c >> +++ b/fs/ext4/crypto.c >> @@ -33,6 +33,8 @@ int ext4_fname_setup_filename(struct inode *dir, const struct qstr *iname, >> struct fscrypt_name name; >> int err; >> >> err = fscrypt_setup_filename(dir, iname, lookup, &name); >> if (err) >> return err; >> >> ext4_fname_from_fscrypt_name(fname, &name); >> >> #if IS_ENABLED(CONFIG_UNICODE) >> err = ext4_fname_setup_ci_filename(dir, iname, fname); >> + if (err) >> + fscrypt_free_filename(&name); >> #endif >> return err; >> } >> @@ -51,6 +53,8 @@ int ext4_fname_prepare_lookup(struct inode *dir, struct dentry *dentry, >> struct fscrypt_name name; >> int err; >> >> err = fscrypt_prepare_lookup(dir, dentry, &name); >> if (err) >> return err; >> >> ext4_fname_from_fscrypt_name(fname, &name); >> >> #if IS_ENABLED(CONFIG_UNICODE) >> err = ext4_fname_setup_ci_filename(dir, &dentry->d_name, fname); >> + if (err) >> + fscrypt_free_filename(&name); >> #endif >> return err; >> } > > This works, but it's a bit weird that the freeing happens on the original struct > fscrypt_name after it has already been "moved" to the struct ext4_filename by > ext4_fname_from_fscrypt_name(). That leaves a dangling pointer in the struct > ext4_filename. Maybe you should call ext4_fname_free_filename() instead, even > though it would do some unnecessary work? That makes sense, specially because fname is a parameter and it's probably a good idea to clean-up everything before returning an error. Thanks. Cheers,
diff --git a/fs/ext4/crypto.c b/fs/ext4/crypto.c index e20ac0654b3f..3c05c7f3415b 100644 --- a/fs/ext4/crypto.c +++ b/fs/ext4/crypto.c @@ -33,6 +33,8 @@ int ext4_fname_setup_filename(struct inode *dir, const struct qstr *iname, #if IS_ENABLED(CONFIG_UNICODE) err = ext4_fname_setup_ci_filename(dir, iname, fname); + if (err) + fscrypt_free_filename(&name); #endif return err; } @@ -51,6 +53,8 @@ int ext4_fname_prepare_lookup(struct inode *dir, struct dentry *dentry, #if IS_ENABLED(CONFIG_UNICODE) err = ext4_fname_setup_ci_filename(dir, &dentry->d_name, fname); + if (err) + fscrypt_free_filename(&name); #endif return err; }