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 A56B733689F; Thu, 2 Jul 2026 16:52:37 +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=1783011159; cv=none; b=Ez1jHE6gevHY4grvAK3QrbkP4y9V6pOKsoC9xImqZZfDcqsIZRJweR9boFrwIqlVv34EV62iFfn0gwb7MTDBFqnWT5tAJ1heza+BrAwFdq2+Mmpj26EJrfIlRUOnltULKUgaUbxcz4zsER8Ot3kf8sxh0zbRXCMn8IZRF/wPFLI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783011159; c=relaxed/simple; bh=rmiLjcaw6/LzKCGn95+kMvlkM4vZSwEFPfU6UJU1BTg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IDhCc6qbVXsI2CvtSRrS7RK5jG6d5bU4PMSomNZfr1YGEm09zIy16JAmiz/MATwsQ3E53905SWyu9cR+YJRA7j4snZSGnse2EU/5P2inVam4GQep4t2KLGiypTyEeSVuLX7JGdC1jqYrT0bZJ2NSOUEracZkh1MzcjMxMZh4p4M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=w3qAEJV8; 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="w3qAEJV8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17A741F000E9; Thu, 2 Jul 2026 16:52:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1783011157; bh=B2VX3Mv+ihHBH8jU9RBo8TycRucF3nLoc1zZXTtcO+8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=w3qAEJV8cDWKx8WCh/01smdNKqOInBMpoQ1kM6/nY7/YMKq0HbMk5qIp2ONDhSAQG l63TP6y9xDQ0sFAJEFEHB+2JN46TiEFFdNNeBwEQO1Sr+grDBtk1eEOzF/1eyxDWT/ a2UvwyEe0baqcjUEE7QMBiV20J/0f541p6lZipnQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Michael Bommarito , Namjae Jeon Subject: [PATCH 6.6 144/175] exfat: fix potential use-after-free in exfat_find_dir_entry() Date: Thu, 2 Jul 2026 18:20:45 +0200 Message-ID: <20260702155118.840751760@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260702155115.766838875@linuxfoundation.org> References: <20260702155115.766838875@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.6-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 @@ -1079,12 +1079,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; } @@ -1095,6 +1095,7 @@ rewind: uniname += EXFAT_FILE_NAME_LEN; len = exfat_extract_uni_name(ep, entry_uniname); + brelse(bh); name_len += len; unichar = *(uniname+len); @@ -1113,6 +1114,7 @@ rewind: continue; } + brelse(bh); if (entry_type & (TYPE_CRITICAL_SEC | TYPE_BENIGN_SEC)) { if (step == DIRENT_STEP_SECD) {