From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 3B42530C15A; Thu, 2 Jul 2026 16:55:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783011337; cv=none; b=kPGJqIgM93pZg8QBKtGUqUIzzs8w+u3yiSImITNl1FMjIY9eRPOTCHlQ0kSGLzHm4fkxOd/BVYwJHerS8LPU41voLrecoYeET6TBPPfTqx84r0Y8AzyW3Upr5HPM2OKp/LF9Ri+F42HB7yzQMleqIF19Uin59TVlCvIpDzaHiug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783011337; c=relaxed/simple; bh=VsTJ0ESiS2k22e5700oqwvTQH4ysQbliYApVMeioHIw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JjW28SvDi1K17D+YJ4DMqsqNRPGU38ENxq8B+ksWpcU1nHCUkHoVi3BPfkpIM32YZPrL5OGZGEsnXP4c5ZuBFr8Pty/zaMaFnAe1DUtzROJvIcDJVjjsv1VBIp2xEyTKKbO6aVyoD8Voi1UD0/FJeT9eIyXfWS5+yrmOHqEXpLY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=PTxGJ5Yt; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="PTxGJ5Yt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0DAF1F000E9; Thu, 2 Jul 2026 16:55:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1783011336; bh=4Ma/0smxp9v1cd2reguCYJ3agR7k2rp5U4058bQQXgo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=PTxGJ5Ytwn7tQbQDEf5H5wEiLxGo8mzeVy7my5NEMGr7l8/AbuPZauy+HGzwPM8ky Jf336tbsgEk85DisSbBVwp8GYnZ+WAPRGvRlxB2dKQ9UtNyNY07Ada3XwNNM5sk4uh f2K/ywf550t435DASiC6BxQ9Pr3bs3PSSDciXyag= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Michael Bommarito , Namjae Jeon Subject: [PATCH 6.18 070/108] exfat: fix potential use-after-free in exfat_find_dir_entry() Date: Thu, 2 Jul 2026 18:21:07 +0200 Message-ID: <20260702155113.561849409@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260702155112.110058792@linuxfoundation.org> References: <20260702155112.110058792@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael Bommarito commit 3f5f8ee9917cc2b9076ac533492d8a200edcabb8 upstream. In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): brelse(bh); if (entry_type == TYPE_EXTEND) { ... len = exfat_extract_uni_name(ep, entry_uniname); ... } After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd ("exfat: Fix potential use after free in exfat_load_upcase_table()"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim. Fixes: ca06197382bd ("exfat: add directory operations") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman --- fs/exfat/dir.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/exfat/dir.c +++ b/fs/exfat/dir.c @@ -1081,12 +1081,12 @@ rewind: continue; } - brelse(bh); if (entry_type == TYPE_EXTEND) { unsigned short entry_uniname[16], unichar; if (step != DIRENT_STEP_NAME || name_len >= MAX_NAME_LENGTH) { + brelse(bh); step = DIRENT_STEP_FILE; continue; } @@ -1097,6 +1097,7 @@ rewind: uniname += EXFAT_FILE_NAME_LEN; len = exfat_extract_uni_name(ep, entry_uniname); + brelse(bh); name_len += len; unichar = *(uniname+len); @@ -1115,6 +1116,7 @@ rewind: continue; } + brelse(bh); if (entry_type & (TYPE_CRITICAL_SEC | TYPE_BENIGN_SEC)) { if (step == DIRENT_STEP_SECD) {