[syzbot] [exfat?] KASAN: stack-out-of-bounds Read in exfat_nls_to_ucs2

[syzbot] [exfat?] KASAN: stack-out-of-bounds Read in exfat_nls_to_ucs2

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    67029a49db6c Merge tag 'trace-v6.18-3' of git://git.kernel..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15b6e542580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=1921939e847e6e87
dashboard link: https://syzkaller.appspot.com/bug?extid=29934710e7fb9cb71f33
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11aa067c580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12ba29e2580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c68ec41538d2/disk-67029a49.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/948793593b2d/vmlinux-67029a49.xz
kernel image: https://storage.googleapis.com/syzbot-assets/db3f32bee746/bzImage-67029a49.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/b8b089d93a49/mount_0.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=130839e2580000)

The issue was bisected to:

commit d01579d590f72d2d91405b708e96f6169f24775a
Author: Ethan Ferguson <ethan.ferguson@zetier.com>
Date:   Tue Sep 30 04:49:00 2025 +0000

    exfat: Add support for FS_IOC_{GET,SET}FSLABEL

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17a099e2580000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=146099e2580000
console output: https://syzkaller.appspot.com/x/log.txt?x=106099e2580000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+29934710e7fb9cb71f33@syzkaller.appspotmail.com
Fixes: d01579d590f7 ("exfat: Add support for FS_IOC_{GET,SET}FSLABEL")

loop0: detected capacity change from 0 to 256
exfat: Deprecated parameter 'namecase'
exFAT-fs (loop0): failed to load upcase table (idx : 0x00010000, chksum : 0x5441951d, utbl_chksum : 0xe619d30d)
==================================================================
BUG: KASAN: stack-out-of-bounds in exfat_nls_to_ucs2+0x706/0x730 fs/exfat/nls.c:619
Read of size 1 at addr ffffc9000383fcc8 by task syz.0.17/5984

CPU: 1 UID: 0 PID: 5984 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xcd/0x630 mm/kasan/report.c:482
 kasan_report+0xe0/0x110 mm/kasan/report.c:595
 exfat_nls_to_ucs2+0x706/0x730 fs/exfat/nls.c:619
 exfat_nls_to_utf16+0xa6/0xf0 fs/exfat/nls.c:647
 exfat_ioctl_set_volume_label+0x15d/0x230 fs/exfat/file.c:524
 exfat_ioctl+0x929/0x1630 fs/exfat/file.c:554
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:597 [inline]
 __se_sys_ioctl fs/ioctl.c:583 [inline]
 __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fbf7418eec9
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:00007ffd30025cd8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fbf743e5fa0 RCX: 00007fbf7418eec9
RDX: 00002000000001c0 RSI: 0000000041009432 RDI: 0000000000000004
RBP: 00007fbf74211f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fbf743e5fa0 R14: 00007fbf743e5fa0 R15: 0000000000000003
 </TASK>

The buggy address belongs to stack of task syz.0.17/5984
 and is located at offset 960 in frame:
 exfat_ioctl_set_volume_label+0x0/0x230 fs/exfat/file.c:507

This frame has 3 objects:
 [32, 36) 'lossy'
 [48, 568) 'uniname'
 [704, 960) 'label'

The buggy address belongs to a vmalloc virtual mapping
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888078e7c000 pfn:0x78e7c
memcg:ffff88803262e802
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 0000000000000000 dead000000000122 0000000000000000
raw: ffff888078e7c000 0000000000000000 00000001ffffffff ffff88803262e802
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO|__GFP_NOWARN), pid 5950, tgid 5950 (dhcpcd-run-hook), ts 127646754846, free_ts 127600338916
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x1c0/0x230 mm/page_alloc.c:1850
 prep_new_page mm/page_alloc.c:1858 [inline]
 get_page_from_freelist+0x10a3/0x3a30 mm/page_alloc.c:3884
 __alloc_frozen_pages_noprof+0x25f/0x2470 mm/page_alloc.c:5183
 alloc_pages_mpol+0x1fb/0x550 mm/mempolicy.c:2416
 alloc_frozen_pages_noprof mm/mempolicy.c:2487 [inline]
 alloc_pages_noprof+0x131/0x390 mm/mempolicy.c:2507
 vm_area_alloc_pages mm/vmalloc.c:3647 [inline]
 __vmalloc_area_node mm/vmalloc.c:3724 [inline]
 __vmalloc_node_range_noprof+0x6f8/0x1480 mm/vmalloc.c:3897
 __vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:3960
 alloc_thread_stack_node kernel/fork.c:311 [inline]
 dup_task_struct kernel/fork.c:881 [inline]
 copy_process+0x2c77/0x76a0 kernel/fork.c:2012
 kernel_clone+0xfc/0x930 kernel/fork.c:2609
 __do_sys_clone+0xce/0x120 kernel/fork.c:2750
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 12 tgid 12 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1394 [inline]
 __free_frozen_pages+0x7df/0x1160 mm/page_alloc.c:2906
 rcu_do_batch kernel/rcu/tree.c:2605 [inline]
 rcu_core+0x79c/0x1530 kernel/rcu/tree.c:2861
 handle_softirqs+0x219/0x8e0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 invoke_softirq kernel/softirq.c:496 [inline]
 __irq_exit_rcu+0x109/0x170 kernel/softirq.c:723
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
 instr_sysvec_call_function_single arch/x86/kernel/smp.c:266 [inline]
 sysvec_call_function_single+0xa4/0xc0 arch/x86/kernel/smp.c:266
 asm_sysvec_call_function_single+0x1a/0x20 arch/x86/include/asm/idtentry.h:704

Memory state around the buggy address:
 ffffc9000383fb80: f2 f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
 ffffc9000383fc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc9000383fc80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
                                              ^
 ffffc9000383fd00: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffc9000383fd80: 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 00 f2 f2 f2
==================================================================


---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

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

[PATCH] exfat: Use str length when converting to utf16

[Edward Adam Davis]

syz reported a stack-out-of-bounds Read in exfat_nls_to_ucs2. [1]

Although general ioctl supports label of FSLABEL_MAX chars, when operating
on label passed in by the user, we should use strnlen to obtain the actual
character length instead of FSLABEL_MAX.

[1]
BUG: KASAN: stack-out-of-bounds in exfat_nls_to_ucs2+0x706/0x730 fs/exfat/nls.c:619
Read of size 1 at addr ffffc9000383fcc8 by task syz.0.17/5984
Call Trace:
 exfat_nls_to_ucs2+0x706/0x730 fs/exfat/nls.c:619
 exfat_nls_to_utf16+0xa6/0xf0 fs/exfat/nls.c:647
 exfat_ioctl_set_volume_label+0x15d/0x230 fs/exfat/file.c:524

Fixes: d01579d590f7 ("exfat: Add support for FS_IOC_{GET,SET}FSLABEL")
Reported-by: syzbot+29934710e7fb9cb71f33@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=29934710e7fb9cb71f33
Tested-by: syzbot+29934710e7fb9cb71f33@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/exfat/file.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index f246cf439588..c4001e1c289d 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -509,8 +509,8 @@ static int exfat_ioctl_get_volume_label(struct super_block *sb, unsigned long ar
 static int exfat_ioctl_set_volume_label(struct super_block *sb,
 					unsigned long arg)
 {
-	int ret = 0, lossy;
-	char label[FSLABEL_MAX];
+	int ret = 0, lossy, len;
+	char label[FSLABEL_MAX] = {0};
 	struct exfat_uni_name uniname;
 
 	if (!capable(CAP_SYS_ADMIN))
@@ -519,9 +519,10 @@ static int exfat_ioctl_set_volume_label(struct super_block *sb,
 	if (copy_from_user(label, (char __user *)arg, FSLABEL_MAX))
 		return -EFAULT;
 
+	len = strnlen(label, FSLABEL_MAX);
 	memset(&uniname, 0, sizeof(uniname));
 	if (label[0]) {
-		ret = exfat_nls_to_utf16(sb, label, FSLABEL_MAX,
+		ret = exfat_nls_to_utf16(sb, label, len,
 					 &uniname, &lossy);
 		if (ret < 0)
 			return ret;
-- 
2.43.0