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 C64943491E1; Thu, 2 Jul 2026 16:44:52 +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=1783010693; cv=none; b=Ay9j9HVh45RF65xIHamsVbYID6u/K2UMvd3NLyuJDOLadyU0CP6j3J3NFXyBZrDBqzPDGawWlI9/BftqOAuOUsNF6AbRas24mUCr0M7Ztjo/sdPnvXTdEM0GPtC62vDSAyAiHoTjd6zMM/s+gUA96cXFDwa4zwlwSoHE4saHLPk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783010693; c=relaxed/simple; bh=ucYuhwXQRhd47J9u4Vy8TZ0DbL40dJDew02hw+bdx5Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jLJFN4NrkL3L8ogB9Na7qxuJ+fO4fGcG2OxAEgfkre+qwXtpRhHUCosdfQbLCZHnXisQ90t2ecWzZf0hploZeYSJqY1zF6EGyQwc2/93hn/VukwK6AF3UaCO7vzUf/mY9tNw//pJRP4HbemIQ/RglmV275uA2fYtR8zsX+ca4F8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=KsDrfEeh; 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="KsDrfEeh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3718E1F000E9; Thu, 2 Jul 2026 16:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1783010692; bh=Yf0xIDmBvcPHKa6VeC9EiO1wtT9fJDnWdgAvz1Exrik=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=KsDrfEehMOgeLhBkUN7zexCenual8fMNot5iWKh2yeAbpGxdHBq2GIMwhWc94Rm4b DBCwFirH9pZzFSRWn5KlATT+0AnIh7xxV9JARaht7/rbkeydg5It1rHT3wS0jPDdiR sBFalz92pHWk1cSG6ysMT/FeFeNFg1AQXo6sCBPM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Michael Bommarito , Namjae Jeon Subject: [PATCH 6.12 162/204] exfat: fix potential use-after-free in exfat_find_dir_entry() Date: Thu, 2 Jul 2026 18:20:19 +0200 Message-ID: <20260702155122.053442897@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260702155118.667618796@linuxfoundation.org> References: <20260702155118.667618796@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.12-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 @@ -1100,12 +1100,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; } @@ -1116,6 +1116,7 @@ rewind: uniname += EXFAT_FILE_NAME_LEN; len = exfat_extract_uni_name(ep, entry_uniname); + brelse(bh); name_len += len; unichar = *(uniname+len); @@ -1134,6 +1135,7 @@ rewind: continue; } + brelse(bh); if (entry_type & (TYPE_CRITICAL_SEC | TYPE_BENIGN_SEC)) { if (step == DIRENT_STEP_SECD) {