[syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    c2c2ccfd4ba7 Merge tag 'net-6.18-rc5' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=151be114580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=41ad820f608cb833
dashboard link: https://syzkaller.appspot.com/bug?extid=5216036fc59c43d1ee02
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11062a58580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16e19084580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/121c46acc3df/disk-c2c2ccfd.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/eb0aef8fb7a1/vmlinux-c2c2ccfd.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a2bba0757aa5/bzImage-c2c2ccfd.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/03760a9baabf/mount_0.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=12084532580000)

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

loop0: detected capacity change from 0 to 256
exFAT-fs (loop0): start_clu is invalid cluster(0x400)
------------[ cut here ]------------
rtmutex deadlock detected
WARNING: CPU: 0 PID: 6071 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock kernel/locking/rtmutex.c:1674 [inline]
WARNING: CPU: 0 PID: 6071 at kernel/locking/rtmutex.c:1674 __rt_mutex_slowlock kernel/locking/rtmutex.c:1734 [inline]
WARNING: CPU: 0 PID: 6071 at kernel/locking/rtmutex.c:1674 __rt_mutex_slowlock_locked+0xed2/0x25e0 kernel/locking/rtmutex.c:1760
Modules linked in:
CPU: 0 UID: 0 PID: 6071 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:rt_mutex_handle_deadlock kernel/locking/rtmutex.c:1674 [inline]
RIP: 0010:__rt_mutex_slowlock kernel/locking/rtmutex.c:1734 [inline]
RIP: 0010:__rt_mutex_slowlock_locked+0xed2/0x25e0 kernel/locking/rtmutex.c:1760
Code: 7c 24 20 dd 4c 8b b4 24 98 00 00 00 0f 85 fd 0a 00 00 48 8b 7c 24 10 e8 4c 50 28 09 90 48 c7 c7 60 fd ea 8a e8 ef 62 e7 ff 90 <0f> 0b 90 90 48 8b 9c 24 80 00 00 00 43 80 3c 3e 00 74 08 4c 89 e7
RSP: 0018:ffffc90003d87a20 EFLAGS: 00010246
RAX: 5bae39e042a2bb00 RBX: ffff88802472e4e0 RCX: ffff88802472da00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90003d87c10 R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: ffffed101710487b R12: ffff88802472f160
R13: ffff88802472da18 R14: 1ffff110048e5e2c R15: dffffc0000000000
FS:  00005555931b8500(0000) GS:ffff888126df9000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffefdd79178 CR3: 000000003e14c000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 rt_mutex_slowlock+0xb5/0x160 kernel/locking/rtmutex.c:1800
 __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline]
 rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244
 inode_lock include/linux/fs.h:980 [inline]
 vfs_rmdir+0xf7/0x520 fs/namei.c:4537
 do_rmdir+0x25f/0x550 fs/namei.c:4603
 __do_sys_unlinkat fs/namei.c:4777 [inline]
 __se_sys_unlinkat fs/namei.c:4771 [inline]
 __x64_sys_unlinkat+0xc2/0xf0 fs/namei.c:4771
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f03a63ff6c9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd1d6ca228 EFLAGS: 00000246 ORIG_RAX: 0000000000000107
RAX: ffffffffffffffda RBX: 00007f03a6655fa0 RCX: 00007f03a63ff6c9
RDX: 0000000000000200 RSI: 0000200000000040 RDI: 0000000000000006
RBP: 00007f03a6481f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f03a6655fa0 R14: 00007f03a6655fa0 R15: 0000000000000003
 </TASK>


---
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 syzkaller@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 syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

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

Re: [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[Namjae Jeon]

[-- Attachment #1: Type: text/plain, Size: 10 bytes --]

#syz test

[-- Attachment #2: 0001-exfat-return-error-if-start_clu-is-invalid.patch --]
[-- Type: text/x-patch, Size: 954 bytes --]

From 25892e8de955d717859f02e8da65c109156c4ee1 Mon Sep 17 00:00:00 2001
From: Namjae Jeon <linkinjeon@kernel.org>
Date: Fri, 7 Nov 2025 16:27:10 +0900
Subject: [PATCH] exfat: return error if ->start_clu is invalid

Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
---
 fs/exfat/namei.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index 745dce29ddb5..4dd09da1aa92 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -657,10 +657,9 @@ static int exfat_find(struct inode *dir, const struct qstr *qname,
 
 	info->start_clu = le32_to_cpu(ep2->dentry.stream.start_clu);
 	if (!is_valid_cluster(sbi, info->start_clu) && info->size) {
-		exfat_warn(sb, "start_clu is invalid cluster(0x%x)",
+		exfat_fs_error(sb, "start_clu is invalid cluster(0x%x)",
 				info->start_clu);
-		info->size = 0;
-		info->valid_size = 0;
+		return -EIO;
 	}
 
 	if (info->valid_size > info->size) {
-- 
2.25.1

Re: [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com
Tested-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com

Tested on:

commit:         4a0c9b33 Merge tag 'probes-fixes-v6.18-rc4' of git://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16bb9084580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=41ad820f608cb833
dashboard link: https://syzkaller.appspot.com/bug?extid=5216036fc59c43d1ee02
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=14711114580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[syzbot]

syzbot has bisected this issue to:

commit 184fa506e392eb78364d9283c961217ff2c0617b
Author: Yuezhang Mo <Yuezhang.Mo@sony.com>
Date:   Mon Oct 28 03:23:36 2024 +0000

    exfat: fix out-of-bounds access of directory entries

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=12217812580000
start commit:   c2c2ccfd4ba7 Merge tag 'net-6.18-rc5' of git://git.kernel...
git tree:       upstream
final oops:     https://syzkaller.appspot.com/x/report.txt?x=11217812580000
console output: https://syzkaller.appspot.com/x/log.txt?x=16217812580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=41ad820f608cb833
dashboard link: https://syzkaller.appspot.com/bug?extid=5216036fc59c43d1ee02
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11062a58580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16e19084580000

Reported-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com
Fixes: 184fa506e392 ("exfat: fix out-of-bounds access of directory entries")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[Namjae Jeon]

[-- Attachment #1: Type: text/plain, Size: 10 bytes --]

#syz test

[-- Attachment #2: 0001-exfat-validate-the-cluster-bitmap-bits-of-root-direc.patch --]
[-- Type: text/x-patch, Size: 2660 bytes --]

From e75c5725762dddfe5b618f8ef9e8ac884d8d66bd Mon Sep 17 00:00:00 2001
From: Namjae Jeon <linkinjeon@kernel.org>
Date: Sat, 8 Nov 2025 20:04:04 +0900
Subject: [PATCH] exfat: validate the cluster bitmap bits of root directory

Syzbot created this issue by testing an image that did not have the root
cluster bitmap bit marked. After accessing a file through the root
directory via exfat_lookup, when creating a file again with mkdir,
the root cluster bit can be allocated for direcotry, which can cause
the root cluster to be zeroed out and the same entry can be allocated
in the same cluster. This patch improved this issue by adding
exfat_test_bitmap to check the cluster bit and validate the clusters
of the root directory.

Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
---
 fs/exfat/balloc.c   | 19 +++++++++++++++++++
 fs/exfat/exfat_fs.h |  1 +
 fs/exfat/super.c    |  6 ++++++
 3 files changed, 26 insertions(+)

diff --git a/fs/exfat/balloc.c b/fs/exfat/balloc.c
index 2d2d510f2372..e6d5b9cb56d6 100644
--- a/fs/exfat/balloc.c
+++ b/fs/exfat/balloc.c
@@ -24,6 +24,25 @@
 #error "BITS_PER_LONG not 32 or 64"
 #endif
 
+bool exfat_test_bitmap(struct super_block *sb, unsigned int clu)
+{
+	int i, b;
+	unsigned int ent_idx;
+	struct exfat_sb_info *sbi = EXFAT_SB(sb);
+
+	if (!is_valid_cluster(sbi, clu))
+		return false;
+
+	ent_idx = CLUSTER_TO_BITMAP_ENT(clu);
+	i = BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx);
+	b = BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx);
+
+	if (!test_bit_le(b, sbi->vol_amap[i]->b_data))
+		return false;
+
+	return true;
+}
+
 /*
  *  Allocation Bitmap Management Functions
  */
diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
index 38210fb6901c..6a317917506c 100644
--- a/fs/exfat/exfat_fs.h
+++ b/fs/exfat/exfat_fs.h
@@ -450,6 +450,7 @@ int exfat_count_num_clusters(struct super_block *sb,
 		struct exfat_chain *p_chain, unsigned int *ret_count);
 
 /* balloc.c */
+bool exfat_test_bitmap(struct super_block *sb, unsigned int clu);
 int exfat_load_bitmap(struct super_block *sb);
 void exfat_free_bitmap(struct exfat_sb_info *sbi);
 int exfat_set_bitmap(struct inode *inode, unsigned int clu, bool sync);
diff --git a/fs/exfat/super.c b/fs/exfat/super.c
index 7f9592856bf7..ce05dc604e13 100644
--- a/fs/exfat/super.c
+++ b/fs/exfat/super.c
@@ -626,6 +626,12 @@ static int __exfat_fill_super(struct super_block *sb,
 		goto free_bh;
 	}
 
+	if (!exfat_test_bitmap(sb, sbi->root_dir)) {
+		exfat_err(sb, "failed to test root cluster bit");
+		ret = -EIO;
+		goto free_alloc_bitmap;
+	}
+
 	ret = exfat_count_used_clusters(sb, &sbi->used_clusters);
 	if (ret) {
 		exfat_err(sb, "failed to scan clusters");
-- 
2.25.1

Re: [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com
Tested-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com

Tested on:

commit:         e811c33b Merge tag 'drm-fixes-2025-11-08' of https://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=134eb812580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=41ad820f608cb833
dashboard link: https://syzkaller.appspot.com/bug?extid=5216036fc59c43d1ee02
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1258d084580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[Namjae Jeon]

[-- Attachment #1: Type: text/plain, Size: 5494 bytes --]

#syz test

On Fri, Nov 7, 2025 at 8:14 AM syzbot
<syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    c2c2ccfd4ba7 Merge tag 'net-6.18-rc5' of git://git.kernel...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=151be114580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=41ad820f608cb833
> dashboard link: https://syzkaller.appspot.com/bug?extid=5216036fc59c43d1ee02
> compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11062a58580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16e19084580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/121c46acc3df/disk-c2c2ccfd.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/eb0aef8fb7a1/vmlinux-c2c2ccfd.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/a2bba0757aa5/bzImage-c2c2ccfd.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/03760a9baabf/mount_0.gz
>   fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=12084532580000)
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com
>
> loop0: detected capacity change from 0 to 256
> exFAT-fs (loop0): start_clu is invalid cluster(0x400)
> ------------[ cut here ]------------
> rtmutex deadlock detected
> WARNING: CPU: 0 PID: 6071 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock kernel/locking/rtmutex.c:1674 [inline]
> WARNING: CPU: 0 PID: 6071 at kernel/locking/rtmutex.c:1674 __rt_mutex_slowlock kernel/locking/rtmutex.c:1734 [inline]
> WARNING: CPU: 0 PID: 6071 at kernel/locking/rtmutex.c:1674 __rt_mutex_slowlock_locked+0xed2/0x25e0 kernel/locking/rtmutex.c:1760
> Modules linked in:
> CPU: 0 UID: 0 PID: 6071 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
> RIP: 0010:rt_mutex_handle_deadlock kernel/locking/rtmutex.c:1674 [inline]
> RIP: 0010:__rt_mutex_slowlock kernel/locking/rtmutex.c:1734 [inline]
> RIP: 0010:__rt_mutex_slowlock_locked+0xed2/0x25e0 kernel/locking/rtmutex.c:1760
> Code: 7c 24 20 dd 4c 8b b4 24 98 00 00 00 0f 85 fd 0a 00 00 48 8b 7c 24 10 e8 4c 50 28 09 90 48 c7 c7 60 fd ea 8a e8 ef 62 e7 ff 90 <0f> 0b 90 90 48 8b 9c 24 80 00 00 00 43 80 3c 3e 00 74 08 4c 89 e7
> RSP: 0018:ffffc90003d87a20 EFLAGS: 00010246
> RAX: 5bae39e042a2bb00 RBX: ffff88802472e4e0 RCX: ffff88802472da00
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffffc90003d87c10 R08: 0000000000000000 R09: 0000000000000000
> R10: dffffc0000000000 R11: ffffed101710487b R12: ffff88802472f160
> R13: ffff88802472da18 R14: 1ffff110048e5e2c R15: dffffc0000000000
> FS:  00005555931b8500(0000) GS:ffff888126df9000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007ffefdd79178 CR3: 000000003e14c000 CR4: 00000000003526f0
> Call Trace:
>  <TASK>
>  rt_mutex_slowlock+0xb5/0x160 kernel/locking/rtmutex.c:1800
>  __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline]
>  rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244
>  inode_lock include/linux/fs.h:980 [inline]
>  vfs_rmdir+0xf7/0x520 fs/namei.c:4537
>  do_rmdir+0x25f/0x550 fs/namei.c:4603
>  __do_sys_unlinkat fs/namei.c:4777 [inline]
>  __se_sys_unlinkat fs/namei.c:4771 [inline]
>  __x64_sys_unlinkat+0xc2/0xf0 fs/namei.c:4771
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f03a63ff6c9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffd1d6ca228 EFLAGS: 00000246 ORIG_RAX: 0000000000000107
> RAX: ffffffffffffffda RBX: 00007f03a6655fa0 RCX: 00007f03a63ff6c9
> RDX: 0000000000000200 RSI: 0000200000000040 RDI: 0000000000000006
> RBP: 00007f03a6481f91 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f03a6655fa0 R14: 00007f03a6655fa0 R15: 0000000000000003
>  </TASK>
>
>
> ---
> 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 syzkaller@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 syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
>
> 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

[-- Attachment #2: 0001-exfat-validate-the-cluster-bitmap-bits-of-directory.patch --]
[-- Type: text/x-patch, Size: 6088 bytes --]

From da53665ae380809427aae9df72d973345a3de7ab Mon Sep 17 00:00:00 2001
From: Namjae Jeon <linkinjeon@kernel.org>
Date: Wed, 12 Nov 2025 09:42:25 +0900
Subject: [PATCH] exfat: validate the cluster bitmap bits of directory

Syzbot created this issue by testing an image that did not have the root
cluster bitmap bit marked. After accessing a file through the root
directory via exfat_lookup, when creating a file again with mkdir,
the root cluster bit can be allocated for direcotry, which can cause
the root cluster to be zeroed out and the same entry can be allocated
in the same cluster. This patch improved this issue by adding
exfat_test_bitmap to validate the cluster bits of the root directory
and directory. And the first cluster bit of the root directory should
never be unset except when storage is corrupted. This bit is set to
allow operations after mount.

Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
---
 fs/exfat/balloc.c   | 28 ++++++++++++++++++++++++----
 fs/exfat/dir.c      |  5 +++++
 fs/exfat/exfat_fs.h |  5 +++--
 fs/exfat/fatent.c   |  6 +++---
 fs/exfat/super.c    | 11 +++++++++++
 5 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/fs/exfat/balloc.c b/fs/exfat/balloc.c
index 2d2d510f2372..b387bf7df65e 100644
--- a/fs/exfat/balloc.c
+++ b/fs/exfat/balloc.c
@@ -183,11 +183,10 @@ void exfat_free_bitmap(struct exfat_sb_info *sbi)
 	kvfree(sbi->vol_amap);
 }
 
-int exfat_set_bitmap(struct inode *inode, unsigned int clu, bool sync)
+int exfat_set_bitmap(struct super_block *sb, unsigned int clu, bool sync)
 {
 	int i, b;
 	unsigned int ent_idx;
-	struct super_block *sb = inode->i_sb;
 	struct exfat_sb_info *sbi = EXFAT_SB(sb);
 
 	if (!is_valid_cluster(sbi, clu))
@@ -202,11 +201,10 @@ int exfat_set_bitmap(struct inode *inode, unsigned int clu, bool sync)
 	return 0;
 }
 
-int exfat_clear_bitmap(struct inode *inode, unsigned int clu, bool sync)
+int exfat_clear_bitmap(struct super_block *sb, unsigned int clu, bool sync)
 {
 	int i, b;
 	unsigned int ent_idx;
-	struct super_block *sb = inode->i_sb;
 	struct exfat_sb_info *sbi = EXFAT_SB(sb);
 
 	if (!is_valid_cluster(sbi, clu))
@@ -226,6 +224,28 @@ int exfat_clear_bitmap(struct inode *inode, unsigned int clu, bool sync)
 	return 0;
 }
 
+bool exfat_test_bitmap(struct super_block *sb, unsigned int clu)
+{
+	int i, b;
+	unsigned int ent_idx;
+	struct exfat_sb_info *sbi = EXFAT_SB(sb);
+
+	if (!sbi->vol_amap)
+		return true;
+
+	if (!is_valid_cluster(sbi, clu))
+		return false;
+
+	ent_idx = CLUSTER_TO_BITMAP_ENT(clu);
+	i = BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx);
+	b = BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx);
+
+	if (!test_bit_le(b, sbi->vol_amap[i]->b_data))
+		return false;
+
+	return true;
+}
+
 /*
  * If the value of "clu" is 0, it means cluster 2 which is the first cluster of
  * the cluster heap.
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index 7229146fe2bf..3045a58e124a 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -604,6 +604,11 @@ static int exfat_find_location(struct super_block *sb, struct exfat_chain *p_dir
 	if (ret)
 		return ret;
 
+	if (!exfat_test_bitmap(sb, clu)) {
+		exfat_err(sb, "failed to test cluster bit(%u)", clu);
+		return -EIO;
+	}
+
 	/* byte offset in cluster */
 	off = EXFAT_CLU_OFFSET(off, sbi);
 
diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
index 38210fb6901c..176fef62574c 100644
--- a/fs/exfat/exfat_fs.h
+++ b/fs/exfat/exfat_fs.h
@@ -452,8 +452,9 @@ int exfat_count_num_clusters(struct super_block *sb,
 /* balloc.c */
 int exfat_load_bitmap(struct super_block *sb);
 void exfat_free_bitmap(struct exfat_sb_info *sbi);
-int exfat_set_bitmap(struct inode *inode, unsigned int clu, bool sync);
-int exfat_clear_bitmap(struct inode *inode, unsigned int clu, bool sync);
+int exfat_set_bitmap(struct super_block *sb, unsigned int clu, bool sync);
+int exfat_clear_bitmap(struct super_block *sb, unsigned int clu, bool sync);
+bool exfat_test_bitmap(struct super_block *sb, unsigned int clu);
 unsigned int exfat_find_free_bitmap(struct super_block *sb, unsigned int clu);
 int exfat_count_used_clusters(struct super_block *sb, unsigned int *ret_count);
 int exfat_trim_fs(struct inode *inode, struct fstrim_range *range);
diff --git a/fs/exfat/fatent.c b/fs/exfat/fatent.c
index 825083634ba2..c9c5f2e3a05e 100644
--- a/fs/exfat/fatent.c
+++ b/fs/exfat/fatent.c
@@ -205,7 +205,7 @@ static int __exfat_free_cluster(struct inode *inode, struct exfat_chain *p_chain
 				cur_cmap_i = next_cmap_i;
 			}
 
-			err = exfat_clear_bitmap(inode, clu, (sync && IS_DIRSYNC(inode)));
+			err = exfat_clear_bitmap(sb, clu, (sync && IS_DIRSYNC(inode)));
 			if (err)
 				break;
 			clu++;
@@ -233,7 +233,7 @@ static int __exfat_free_cluster(struct inode *inode, struct exfat_chain *p_chain
 				cur_cmap_i = next_cmap_i;
 			}
 
-			if (exfat_clear_bitmap(inode, clu, (sync && IS_DIRSYNC(inode))))
+			if (exfat_clear_bitmap(sb, clu, (sync && IS_DIRSYNC(inode))))
 				break;
 
 			if (sbi->options.discard) {
@@ -409,7 +409,7 @@ int exfat_alloc_cluster(struct inode *inode, unsigned int num_alloc,
 		}
 
 		/* update allocation bitmap */
-		if (exfat_set_bitmap(inode, new_clu, sync_bmap)) {
+		if (exfat_set_bitmap(sb, new_clu, sync_bmap)) {
 			ret = -EIO;
 			goto free_cluster;
 		}
diff --git a/fs/exfat/super.c b/fs/exfat/super.c
index 7f9592856bf7..e440ab6b5562 100644
--- a/fs/exfat/super.c
+++ b/fs/exfat/super.c
@@ -626,6 +626,17 @@ static int __exfat_fill_super(struct super_block *sb,
 		goto free_bh;
 	}
 
+	if (!exfat_test_bitmap(sb, sbi->root_dir)) {
+		exfat_warn(sb, "failed to test first cluster bit of root dir(%u)",
+			   sbi->root_dir);
+		/*
+		 * The first cluster bit of the root directory should never
+		 * be unset except when storage is corrupted. This bit is
+		 * set to allow operations after mount.
+		 */
+		exfat_set_bitmap(sb, sbi->root_dir, false);
+	}
+
 	ret = exfat_count_used_clusters(sb, &sbi->used_clusters);
 	if (ret) {
 		exfat_err(sb, "failed to scan clusters");
-- 
2.25.1

Re: [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com
Tested-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com

Tested on:

commit:         24172e0d Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15c48212580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=41ad820f608cb833
dashboard link: https://syzkaller.appspot.com/bug?extid=5216036fc59c43d1ee02
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=16a8d60a580000

Note: testing is done by a robot and is best-effort only.