From: Namjae Jeon <linkinjeon@kernel.org>
To: syzbot <syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
sj1557.seo@samsung.com, syzkaller-bugs@googlegroups.com,
"Yuezhang.Mo" <Yuezhang.Mo@sony.com>
Subject: Re: [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2)
Date: Wed, 12 Nov 2025 12:37:03 +0900 [thread overview]
Message-ID: <CAKYAXd86eFyX5sVi_5exaFJ-wGn2U16n_L1c9ouDBnFGPuH_qg@mail.gmail.com> (raw)
In-Reply-To: <690d2bd5.a70a0220.22f260.000f.GAE@google.com>
[-- 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
next prev parent reply other threads:[~2025-11-12 3:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 23:14 [syzbot] [exfat?] WARNING in __rt_mutex_slowlock_locked (2) syzbot
2025-11-07 7:29 ` Namjae Jeon
2025-11-07 8:29 ` syzbot
2025-11-07 9:11 ` syzbot
2025-11-08 11:06 ` Namjae Jeon
2025-11-08 11:46 ` syzbot
2025-11-12 3:37 ` Namjae Jeon [this message]
2025-11-12 4:07 ` syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKYAXd86eFyX5sVi_5exaFJ-wGn2U16n_L1c9ouDBnFGPuH_qg@mail.gmail.com \
--to=linkinjeon@kernel.org \
--cc=Yuezhang.Mo@sony.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sj1557.seo@samsung.com \
--cc=syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).