kernel/linux.git/fs/exfat, branch v7.1.12

exfat: fix implicit declaration of brelse()

2026-07-24T14:21:26+00:00

[ Upstream commit f0d1b2e1e02c11e29c953f22a485449e3da2a575 ] exfat_cluster_walk() calls brelse(bh) without including the header that declares the function, causing the following build error: fs/exfat/exfat_fs.h:542:9: error: implicit declaration of function ‘brelse’ [-Werror=implicit-function-declaration] Fix this by adding the missing buffer_head.h in exfat_fs.h. Acked-by: Christoph Hellwig Acked-by: "Darrick J. Wong" Signed-off-by: Namjae Jeon Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

exfat: add data_start_bytes and exfat_cluster_to_phys_bytes() helper

2026-07-24T14:21:26+00:00

[ Upstream commit 3b9450beeb961c7ddf4cccddba37fcfa6d1fcb7a ] This caches the data area start offset in bytes (data_start_bytes) and introduces a helper function exfat_cluster_to_phys_bytes() to compute the physical byte position of a given cluster. Acked-by: Christoph Hellwig Acked-by: "Darrick J. Wong" Signed-off-by: Namjae Jeon Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

exfat: add balloc parameter to exfat_map_cluster() for iomap support

2026-07-24T14:21:26+00:00

[ Upstream commit 3474416bb9abafca2e79b7ff700a100b7e8bc766 ] In preparation for supporting the iomap infrastructure, we need to know whether a new cluster was allocated or not in exfat_map_cluster(). Add an optional 'bool *balloc' output parameter. When a new cluster is allocated, *balloc is set to true. Pass NULL from exfat_get_block() to preserve the existing behavior. Acked-by: Christoph Hellwig Acked-by: "Darrick J. Wong" Signed-off-by: Namjae Jeon Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

exfat: replace unsafe macros with static inline functions

2026-07-24T14:21:26+00:00

[ Upstream commit f07db38084dc45162d5fe2871ed72674ddc0f9ae ] The current exFAT driver relies on various macros for unit conversions between clusters, blocks, sectors, and directory entries. These macros are structurally unsafe as they lack type enforcement and are prone to potential integer overflows during bit-shift operations, especially on 64-bit architectures. Replace all arithmetic macros with static inline functions to provide strict type checking and explicit casting. Acked-by: Christoph Hellwig Acked-by: "Darrick J. Wong" Signed-off-by: Namjae Jeon Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

exfat: bound uniname advance in exfat_find_dir_entry()

2026-07-18T14:55:44+00:00

commit 3a1230e7b043c62737b05a3e9275ca83a43ad20a upstream. In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: if (++order == 2) uniname = p_uniname->name; else uniname += EXFAT_FILE_NAME_LEN; len = exfat_extract_uni_name(ep, entry_uniname); name_len += len; unichar = *(uniname+len); *(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba ("exfat: check if filename entries exceeds max filename length")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer. Fixes: ca06197382bd ("exfat: add directory operations") Cc: stable@vger.kernel.org Suggested-by: Namjae Jeon Signed-off-by: Bryam Vargas Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman

exfat: preserve benign secondary entries during rename and move

2026-07-18T14:55:44+00:00

commit 942296784b2a9439651750c42f540bf2579b330f upstream. Commit 8258ef28001a ("exfat: handle unreconized benign secondary entries") added cluster freeing for benign secondary entries inside exfat_remove_entries(). However, exfat_remove_entries() is also called from the rename and move paths (exfat_rename_file and exfat_move_file), where the old entry set is being relocated rather than deleted. This causes benign secondary entries such as vendor extension entries to be silently destroyed on rename or cross-directory move, violating the exFAT spec requirement (section 8.2) that implementations preserve unrecognized benign secondary entries. Fix this by adding a free_benign parameter to exfat_remove_entries() so callers can suppress cluster freeing during relocation, and extending exfat_init_ext_entry() to copy trailing benign secondary entries from the old entry set into the new one internally. Also clean up the error paths to delete newly allocated entries on failure. Fixes: 8258ef28001a ("exfat: handle unreconized benign secondary entries") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-fsdevel/CAG7tbBV--waov7XVu2FHQEc6paR92dufS=em9DW5Kzsrpu3iQg@mail.gmail.com/ Signed-off-by: Rochan Avlur Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman

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

2026-07-04T11:45:06+00:00

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

Merge tag 'exfat-for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat

2026-04-13T23:57:31+00:00

Pull exfat updates from Namjae Jeon: - Implement FALLOC_FL_ALLOCATE_RANGE to add support for preallocating clusters without zeroing, helping to reduce file fragmentation - Add a unified block readahead helper for FAT chain conversion, bitmap allocation, and directory entry lookups - Optimize exfat_chain_cont_cluster() by caching buffer heads to minimize mark_buffer_dirty() and mirroring overhead during NO_FAT_CHAIN to FAT_CHAIN conversion - Switch to truncate_inode_pages_final() in evict_inode() to prevent BUG_ON caused by shadow entries during reclaim - Fix a 32-bit truncation bug in directory entry calculations by ensuring proper bitwise coercion - Fix sb->s_maxbytes calculation to correctly reflect the maximum possible volume size for a given cluster size, resolving xfstests generic/213 - Introduced exfat_cluster_walk() helper to traverse FAT chains by a specified step, handling both ALLOC_NO_FAT_CHAIN and ALLOC_FAT_CHAIN modes - Introduced exfat_chain_advance() helper to advance an exfat_chain structure, updating both the current cluster and remaining size - Remove dead assignments and fix Smatch warnings * tag 'exfat-for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat: exfat: use exfat_chain_advance helper exfat: introduce exfat_chain_advance helper exfat: remove NULL cache pointer case in exfat_ent_get exfat: use exfat_cluster_walk helper exfat: introduce exfat_cluster_walk helper exfat: fix incorrect directory checksum after rename to shorter name exfat: fix s_maxbytes exfat: fix passing zero to ERR_PTR() in exfat_mkdir() exfat: fix error handling for FAT table operations exfat: optimize exfat_chain_cont_cluster with cached buffer heads exfat: drop redundant sec parameter from exfat_mirror_bh exfat: use readahead helper in exfat_get_dentry exfat: use readahead helper in exfat_allocate_bitmap exfat: add block readahead in exfat_chain_cont_cluster exfat: add fallocate FALLOC_FL_ALLOCATE_RANGE support exfat: Fix bitwise operation having different size exfat: Drop dead assignment of num_clusters exfat: use truncate_inode_pages_final() at evict_inode()

exfat: use exfat_chain_advance helper

2026-04-03T13:41:10+00:00

Replace open-coded cluster chain walking logic with exfat_chain_advance() across exfat_readdir, exfat_find_dir_entry, exfat_count_dir_entries, exfat_search_empty_slot and exfat_check_dir_empty. Signed-off-by: Chi Zhiling Reviewed-by: Sungjong Seo Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon

exfat: introduce exfat_chain_advance helper

2026-04-03T13:41:08+00:00

Introduce exfat_chain_advance() to walk a exfat_chain structure by a given step, updating both ->dir and ->size fields atomically. This helper handles both ALLOC_NO_FAT_CHAIN and ALLOC_FAT_CHAIN modes with proper boundary checking. Suggested-by: Yuezhang Mo Signed-off-by: Chi Zhiling Reviewed-by: Sungjong Seo Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon