[syzbot] [exfat?] KCSAN: data-race in fat12_ent_put / fat_mirror_bhs

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: de0674d9bc69 Merge tag 'for-6.19-rc8-tag' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15f240aa580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8e27f4588a0f2183
dashboard link: https://syzkaller.appspot.com/bug?extid=51b4c65bb770155d058f
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/bfedab2f6279/disk-de0674d9.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f012a4cb8d82/vmlinux-de0674d9.xz
kernel image: https://storage.googleapis.com/syzbot-assets/acb727c49110/bzImage-de0674d9.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+51b4c6...@syzkaller.appspotmail.com

==================================================================
BUG: KCSAN: data-race in fat12_ent_put / fat_mirror_bhs

read-write to 0xffff888129151032 of 1 bytes by task 4937 on cpu 1:
fat12_ent_put+0xc4/0x170 fs/fat/fatent.c:165
fat_ent_write+0x6c/0xe0 fs/fat/fatent.c:417
fat_chain_add+0x16c/0x490 fs/fat/misc.c:136
fat_add_cluster fs/fat/inode.c:113 [inline]
__fat_get_block fs/fat/inode.c:155 [inline]
fat_get_block+0x46c/0x5e0 fs/fat/inode.c:190
__block_write_begin_int+0x400/0xf90 fs/buffer.c:2145
block_write_begin fs/buffer.c:2256 [inline]
cont_write_begin+0x5fe/0x970 fs/buffer.c:2594
fat_write_begin+0x4f/0xe0 fs/fat/inode.c:230
generic_perform_write+0x183/0x490 mm/filemap.c:4314
__generic_file_write_iter+0x9e/0x120 mm/filemap.c:4431
generic_file_write_iter+0x8d/0x310 mm/filemap.c:4457
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x5a6/0x9f0 fs/read_write.c:686
ksys_write+0xdc/0x1a0 fs/read_write.c:738
__do_sys_write fs/read_write.c:749 [inline]
__se_sys_write fs/read_write.c:746 [inline]
__x64_sys_write+0x40/0x50 fs/read_write.c:746
x64_sys_call+0x2847/0x3000 arch/x86/include/generated/asm/syscalls_64.h:2
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff888129151000 of 512 bytes by task 4940 on cpu 0:
fat_mirror_bhs+0x1df/0x320 fs/fat/fatent.c:395
fat_alloc_clusters+0xb48/0xc50 fs/fat/fatent.c:543
fat_add_cluster fs/fat/inode.c:108 [inline]
__fat_get_block fs/fat/inode.c:155 [inline]
fat_get_block+0x258/0x5e0 fs/fat/inode.c:190
__block_write_begin_int+0x400/0xf90 fs/buffer.c:2145
block_write_begin fs/buffer.c:2256 [inline]
cont_write_begin+0x5fe/0x970 fs/buffer.c:2594
fat_write_begin+0x4f/0xe0 fs/fat/inode.c:230
generic_perform_write+0x183/0x490 mm/filemap.c:4314
__generic_file_write_iter+0x9e/0x120 mm/filemap.c:4431
generic_file_write_iter+0x8d/0x310 mm/filemap.c:4457
__kernel_write_iter+0x319/0x590 fs/read_write.c:619
dump_emit_page fs/coredump.c:1298 [inline]
dump_user_range+0xa7d/0xdb0 fs/coredump.c:1372
elf_core_dump+0x21a2/0x2330 fs/binfmt_elf.c:2111
coredump_write+0xacf/0xdf0 fs/coredump.c:1049
do_coredump fs/coredump.c:1126 [inline]
vfs_coredump+0x26bc/0x3120 fs/coredump.c:1200
get_signal+0xd7b/0xf60 kernel/signal.c:3019
arch_do_signal_or_restart+0x96/0x450 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
exit_to_user_mode_loop kernel/entry/common.c:75 [inline]
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
irqentry_exit_to_user_mode_prepare include/linux/irq-entry-common.h:270 [inline]
irqentry_exit_to_user_mode include/linux/irq-entry-common.h:339 [inline]
irqentry_exit+0xf7/0x510 kernel/entry/common.c:196
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 4940 Comm: syz.3.398 Not tainted syzkaller #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
==================================================================
syz.3.398 (4940) used greatest stack depth: 8696 bytes left


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Dmitry Vyukov]

FWIW this is how LLM explained why this race is harmful. It does not
look totally bogus to me.

=======

The data race occurs between `fat12_ent_put()` and `fat_mirror_bhs()`
in the FAT filesystem implementation.

### Analysis:
1. **Task 1 (`fat12_ent_put`)**: This function is responsible for
updating a 12-bit FAT entry. Because FAT12 entries are 1.5 bytes long
and can span byte boundaries, updating an entry involves a
read-modify-write on two bytes. This is protected by the
`fat12_entry_lock` spinlock to ensure atomicity against other FAT12
entry updates. In the reported stack trace, it is called from
`fat_alloc_clusters()`, which also holds the `lock_fat` mutex.
2. **Task 2 (`fat_mirror_bhs`)**: This function copies the "main" FAT
blocks (held in `buffer_head`s) to the backup FAT copies (mirrors) on
the disk. It uses `memcpy()` to copy the entire block data. In the
reported stack trace, it is called from `fat_alloc_clusters()`.
3. **The Race**: In `fat_alloc_clusters()`, the `lock_fat` mutex is
released *before* calling `fat_mirror_bhs()`. This allows another task
(like Task 1) to acquire the `lock_fat` mutex and begin modifying the
same FAT block that Task 2 is currently mirroring. Since
`fat_mirror_bhs()` does not take the `fat12_entry_lock` spinlock, and
`memcpy()` is not atomic, Task 2 can read a FAT entry in a partially
updated (torn) state.
4. **Impact**: If a torn FAT entry is copied to the mirror FAT and
subsequently written to disk, the filesystem metadata becomes
corrupted. In FAT12, a torn read can result in a cluster pointer that
is neither the old nor the new value, potentially pointing to a random
cluster. This leads to cross-linked files, lost data, or filesystem
inconsistency. While the main FAT might eventually be updated
correctly, there is a window where the mirror is corrupted on disk,
and if a crash occurs, the filesystem is left in an inconsistent
state. A similar race condition exists for `fat_sync_bhs()`, which
flushes the main FAT block to disk.

### Conclusion:
This data race is **harmful**. It involves concurrent access to shared
filesystem metadata without sufficient synchronization, leading to the
possibility of writing inconsistent/corrupted metadata to the disk.
Filesystem metadata integrity is critical, and torn writes are a
well-known source of serious filesystem corruption. The inconsistency
in locking between `fat_free_clusters()` (which holds the lock during
mirroring) and `fat_alloc_clusters()` (which does not) further
indicates that this is an unsafe oversight.

[OGAWA Hirofumi]

syzbot <syzbot+51b4c6...@syzkaller.appspotmail.com> writes:

> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: de0674d9bc69 Merge tag 'for-6.19-rc8-tag' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15f240aa580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=8e27f4588a0f2183
> dashboard link: https://syzkaller.appspot.com/bug?extid=51b4c65bb770155d058f
> compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/bfedab2f6279/disk-de0674d9.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/f012a4cb8d82/vmlinux-de0674d9.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/acb727c49110/bzImage-de0674d9.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+51b4c6...@syzkaller.appspotmail.com

This looks like same with the following thread.

https://lore.kernel.org/all/20250902081727.7...@gmail.com/

And this temporary inconsistency will be fixed until unmount, so it
should be no corruption by this race. Let me know if corruption remained
after unmount.

Thanks.

--
OGAWA Hirofumi <hiro...@mail.parknet.co.jp>