exfat: fix potential use-after-free in exfat_find_dir_entry()

[PATCH] exfat: fix potential use-after-free in exfat_find_dir_entry()

Posted by Michael Bommarito 1 month, 4 weeks ago

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
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Assisted-by: Claude:claude-opus-4-7
---
 fs/exfat/dir.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index ac008ccaa97d..561fd2349218 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -1027,12 +1027,12 @@ int exfat_find_dir_entry(struct super_block *sb, struct exfat_inode_info *ei,
 				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;
 				}
@@ -1043,6 +1043,7 @@ int exfat_find_dir_entry(struct super_block *sb, struct exfat_inode_info *ei,
 					uniname += EXFAT_FILE_NAME_LEN;
 
 				len = exfat_extract_uni_name(ep, entry_uniname);
+				brelse(bh);
 				name_len += len;
 
 				unichar = *(uniname+len);
@@ -1061,6 +1062,7 @@ int exfat_find_dir_entry(struct super_block *sb, struct exfat_inode_info *ei,
 				continue;
 			}
 
+			brelse(bh);
 			if (entry_type &
 					(TYPE_CRITICAL_SEC | TYPE_BENIGN_SEC)) {
 				if (step == DIRENT_STEP_SECD) {
-- 
2.53.0

Re: [PATCH] exfat: fix potential use-after-free in exfat_find_dir_entry()

Posted by Namjae Jeon 1 month, 3 weeks ago

On Thu, Apr 23, 2026 at 12:59 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> 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
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> Assisted-by: Claude:claude-opus-4-7
Applied it to #dev.
Thanks!