From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E4CBC7EE2C for ; Mon, 15 May 2023 17:57:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244034AbjEOR4t (ORCPT ); Mon, 15 May 2023 13:56:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239975AbjEORzy (ORCPT ); Mon, 15 May 2023 13:55:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21C3F1CA40 for ; Mon, 15 May 2023 10:54:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C87EC621EB for ; Mon, 15 May 2023 17:53:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C111FC433EF; Mon, 15 May 2023 17:53:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1684173237; bh=oRZ9Zk8JKRJs7mhvky8oFjkc1pDdqMhApMAnCGrtaKY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XR4UGWK4OcZZR7AHtCQobXBnIAuf/8QHoTBLqUVGvZFxu2/Uqm/jgdiKS+1WDyZxG u4Kbq4GFuvN6/suAVmlsGS0el+MpG+XJMpL9U2zslRISiYRzAISqSNBdMa5eI6CpEB hfPHENN91QN5IRTk/B97rlmsP9x89BSFgD3iZUT8= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, =?UTF-8?q?M=C3=A5rten=20Lindahl?= , Zhihao Cheng , Richard Weinberger Subject: [PATCH 5.4 029/282] ubifs: Free memory for tmpfile name Date: Mon, 15 May 2023 18:26:47 +0200 Message-Id: <20230515161723.151200436@linuxfoundation.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230515161722.146344674@linuxfoundation.org> References: <20230515161722.146344674@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mårten Lindahl commit 1fb815b38bb31d6af9bd0540b8652a0d6fe6cfd3 upstream. When opening a ubifs tmpfile on an encrypted directory, function fscrypt_setup_filename allocates memory for the name that is to be stored in the directory entry, but after the name has been copied to the directory entry inode, the memory is not freed. When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program 'tmpfile' just opening a tmpfile: unreferenced object 0xffff88810178f380 (size 32): comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename ubifs_tmpfile vfs_tmpfile path_openat Free this memory after it has been copied to the inode. Signed-off-by: Mårten Lindahl Reviewed-by: Zhihao Cheng Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman --- fs/ubifs/dir.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -433,6 +433,7 @@ static int do_tmpfile(struct inode *dir, mutex_unlock(&dir_ui->ui_mutex); ubifs_release_budget(c, &req); + fscrypt_free_filename(&nm); return 0;