[syzbot] [raid?] UBSAN: array-index-out-of-bounds in super_90_sync

[syzbot] [raid?] UBSAN: array-index-out-of-bounds in super_90_sync

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    893e11787f78 Merge tag 'x86_urgent_for_7.3-rc3' of git://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11af7af9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
dashboard link: https://syzkaller.appspot.com/bug?extid=9e3014263a35700ab49b
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/7d6d05cecce7/disk-893e1178.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f4fa34852d36/vmlinux-893e1178.xz
kernel image: https://storage.googleapis.com/syzbot-assets/5a45af623528/bzImage-893e1178.xz

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

md: async del_gendisk mode will be removed in future, please upgrade to mdadm-4.5+
------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in drivers/md/md.c:1697:17
index 124 is out of range for type 'mdp_disk_t [27]'
CPU: 1 UID: 0 PID: 10197 Comm: syz.3.1362 Tainted: G             L      syzkaller #0 PREEMPT(full) 
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233
 __ubsan_handle_out_of_bounds+0xcc/0xf0 lib/ubsan.c:455
 super_90_sync+0x1eed/0x1ff0 drivers/md/md.c:1697
 sync_super drivers/md/md.c:2505 [inline]
 sync_sbs drivers/md/md.c:2747 [inline]
 md_update_sb+0xbba/0x2840 drivers/md/md.c:2923
 state_store+0x31e/0x1340 drivers/md/md.c:3245
 rdev_attr_store+0x465/0x560 drivers/md/md.c:3768
 sysfs_kf_write+0xf2/0x150 fs/sysfs/file.c:145
 kernfs_fop_write_iter+0x3e0/0x5f0 fs/kernfs/file.c:345
 new_sync_write fs/read_write.c:595 [inline]
 vfs_write+0x6af/0x1050 fs/read_write.c:687
 ksys_write+0x12a/0x250 fs/read_write.c:739
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f977e59e159
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f977f3cb028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f977e825fa0 RCX: 00007f977e59e159
RDX: 000000000000000b RSI: 0000200000000a00 RDI: 0000000000000006
RBP: 00007f977e63503b R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f977e826038 R14: 00007f977e825fa0 R15: 00007ffef91f5d68
 </TASK>
---[ end trace ]---


---
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 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] [raid?] UBSAN: array-index-out-of-bounds in super_90_sync

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    2f0c1cf72f46 Merge tag 's390-7.3-3' of git://git.kernel.or..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=14afd5f9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
dashboard link: https://syzkaller.appspot.com/bug?extid=9e3014263a35700ab49b
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12afd5f9580000

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

------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in drivers/md/md.c:1697:17
index 124 is out of range for type 'mdp_disk_t [27]'
CPU: 1 UID: 0 PID: 6018 Comm: syz-executor186 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233
 __ubsan_handle_out_of_bounds+0xcc/0xf0 lib/ubsan.c:455
 super_90_sync+0x1eed/0x1ff0 drivers/md/md.c:1697
 sync_super drivers/md/md.c:2505 [inline]
 sync_sbs drivers/md/md.c:2747 [inline]
 md_update_sb+0xbba/0x2840 drivers/md/md.c:2923
 state_store+0x31e/0x1340 drivers/md/md.c:3245
 rdev_attr_store+0x1d9/0x560 drivers/md/md.c:3768
 sysfs_kf_write+0xf2/0x150 fs/sysfs/file.c:145
 kernfs_fop_write_iter+0x3e0/0x5f0 fs/kernfs/file.c:345
 new_sync_write fs/read_write.c:595 [inline]
 vfs_write+0x6af/0x1050 fs/read_write.c:687
 ksys_write+0x12a/0x250 fs/read_write.c:739
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f84634ad6f7
Code: 48 89 fa 4c 89 df e8 98 1d 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
RSP: 002b:00007fff04c70ef0 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00005555934c5400 RCX: 00007f84634ad6f7
RDX: 0000000000000008 RSI: 00007f84634e9c12 RDI: 0000000000000003
RBP: 00007f84634e9c12 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff04c70fc0
R13: 00007f84634e9b5f R14: 00007fff04c710d0 R15: 0000000000000002
 </TASK>
---[ end trace ]---


---
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.

[PATCH] md: add max_disks bound check in older version

[Aaditya Kansal]

#syz test

syzbot reported array-index-out-of-bounds in super_90_sync()
    UBSAN: array-index-out-of-bounds in drivers/md/md.c:1697:17
    index 124 is out of range for type 'mdp_disk_t [27]'
    CPU: 1 UID: 0 PID: 10197 Comm: syz.3.1362 Tainted: G    L
    syzkaller #0 PREEMPT(full)
    Tainted: [L]=SOFTLOCKUP
    Hardware name: Google Google Compute Engine/Google Compute Engine,
    BIOS Google 08/05/2026
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
     ubsan_epilogue+0xa/0x30 lib/ubsan.c:233
     __ubsan_handle_out_of_bounds+0xcc/0xf0 lib/ubsan.c:455
     super_90_sync+0x1eed/0x1ff0 drivers/md/md.c:1697
 ...

super_90_sync() exists for older version 0.90, which supports up to 27
maximum disks (MD_SB_DISKS). This function doesn't contain any bound checks for
raid disks. The repro wrote higher value (124) in raid_disks sysfs attribute
to trigger this bug.

Add bound checks in super_90_sync() to prevent index-out-of-bounds error. This
bound check hardens super_90_sync() function, such that it can catch max disk
index-out-of-bounds coming from any path, including raid_disks
attribute.

Signed-off-by: Aaditya Kansal <aadityakansal390@gmail.com>
---
 drivers/md/md.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 680b34a63cb3..f5fce41637f1 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -1693,6 +1693,12 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
 			desc_nr = rdev2->raid_disk;
 		else
 			desc_nr = next_spare++;
+
+		if (desc_nr >= MD_SB_DISKS) {
+			pr_warn("md: raid_disks = %d exceeds max_disks = %d for version 0.90\n",
+					desc_nr, MD_SB_DISKS);
+			continue;
+		}
 		rdev2->desc_nr = desc_nr;
 		d = &sb->disks[rdev2->desc_nr];
 		nr_disks++;
@@ -1722,7 +1728,7 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
 			d->state |= (1<<MD_DISK_FAILFAST);
 	}
 	/* now set the "removed" and "faulty" bits on any missing devices */
-	for (i=0 ; i < mddev->raid_disks ; i++) {
+	for (i = 0; i < mddev->raid_disks && i < MD_SB_DISKS; i++) {
 		mdp_disk_t *d = &sb->disks[i];
 		if (d->state == 0 && d->number == 0) {
 			d->number = i;
--
2.55.0

Re: [PATCH] md: add max_disks bound check in older version

[syzbot]

> #syz test

"" does not look like a valid git branch or commit.

>
> syzbot reported array-index-out-of-bounds in super_90_sync()
>     UBSAN: array-index-out-of-bounds in drivers/md/md.c:1697:17
>     index 124 is out of range for type 'mdp_disk_t [27]'
>     CPU: 1 UID: 0 PID: 10197 Comm: syz.3.1362 Tainted: G    L
>     syzkaller #0 PREEMPT(full)
>     Tainted: [L]=SOFTLOCKUP
>     Hardware name: Google Google Compute Engine/Google Compute Engine,
>     BIOS Google 08/05/2026
>     Call Trace:
>      <TASK>
>      __dump_stack lib/dump_stack.c:94 [inline]
>      dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
>      ubsan_epilogue+0xa/0x30 lib/ubsan.c:233
>      __ubsan_handle_out_of_bounds+0xcc/0xf0 lib/ubsan.c:455
>      super_90_sync+0x1eed/0x1ff0 drivers/md/md.c:1697
>  ...
>
> super_90_sync() exists for older version 0.90, which supports up to 27
> maximum disks (MD_SB_DISKS). This function doesn't contain any bound checks for
> raid disks. The repro wrote higher value (124) in raid_disks sysfs attribute
> to trigger this bug.
>
> Add bound checks in super_90_sync() to prevent index-out-of-bounds error. This
> bound check hardens super_90_sync() function, such that it can catch max disk
> index-out-of-bounds coming from any path, including raid_disks
> attribute.
>
> Signed-off-by: Aaditya Kansal <aadityakansal390@gmail.com>
> ---
>  drivers/md/md.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 680b34a63cb3..f5fce41637f1 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -1693,6 +1693,12 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
>  			desc_nr = rdev2->raid_disk;
>  		else
>  			desc_nr = next_spare++;
> +
> +		if (desc_nr >= MD_SB_DISKS) {
> +			pr_warn("md: raid_disks = %d exceeds max_disks = %d for version 0.90\n",
> +					desc_nr, MD_SB_DISKS);
> +			continue;
> +		}
>  		rdev2->desc_nr = desc_nr;
>  		d = &sb->disks[rdev2->desc_nr];
>  		nr_disks++;
> @@ -1722,7 +1728,7 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
>  			d->state |= (1<<MD_DISK_FAILFAST);
>  	}
>  	/* now set the "removed" and "faulty" bits on any missing devices */
> -	for (i=0 ; i < mddev->raid_disks ; i++) {
> +	for (i = 0; i < mddev->raid_disks && i < MD_SB_DISKS; i++) {
>  		mdp_disk_t *d = &sb->disks[i];
>  		if (d->state == 0 && d->number == 0) {
>  			d->number = i;
> --
> 2.55.0
>

Re: [PATCH] md: add max_disks bound check in older version

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] The patch prevents an out-of-bounds write in `super_90_sync()` by adding a bounds check, but leaves an out-of-bounds read unhandled at the end of the function, which can be exploited as a kernel information leak.
- [High] A maliciously crafted version 0.90 superblock on disk can trigger an out-of-bounds read in `super_90_validate()` due to completely missing bounds validation of `this_disk.number` when the superblock is loaded.
--

commit bca793f34834f5048d928e016591b4ea5cf035dc
Author: Aaditya Kansal <aadityakansal390@gmail.com>

md: add max_disks bound check in older version

This commit adds bounds checking for raid_disks in super_90_sync() to prevent
an array-index-out-of-bounds access. It addresses a syzbot report where
a high value written to the raid_disks sysfs attribute triggered the bug.

> diff --git a/drivers/md/md.c b/drivers/md/md.c
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -1693,6 +1693,12 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
>  			desc_nr = rdev2->raid_disk;
>  		else
>  			desc_nr = next_spare++;
> +
> +		if (desc_nr >= MD_SB_DISKS) {
> +			pr_warn("md: raid_disks = %d exceeds max_disks = %d for version 0.90\n",
> +					desc_nr, MD_SB_DISKS);
> +			continue;
> +		}

[Severity: Critical]
This isn't a bug introduced by this patch, but could this continue statement
leave rdev->desc_nr unvalidated, leading to an out-of-bounds read later?

If an attacker provides a malicious block device with a version 0.90
superblock containing a large this_disk.number, super_90_load() assigns
this to rdev->desc_nr. Later, when md_update_sb() calls super_90_sync(),
the newly added bounds check skips updating rdev2->desc_nr because of the
continue statement.

At the end of super_90_sync(), the unvalidated rdev->desc_nr is then
unconditionally used to index into the array:

drivers/md/md.c:super_90_sync() {
    ...
    sb->this_disk = sb->disks[rdev->desc_nr];
    sb->sb_csum = calc_sb_csum(sb);
}

This copies 128 bytes from memory far past the 4KB superblock page into
sb->this_disk. The updated superblock is then written back to disk, which
can persistently leak out-of-bounds kernel memory to the attacker.
Alternatively, if raid_disks is manipulated via sysfs for a new disk,
rdev->desc_nr could remain -1, triggering a UBSAN out-of-bounds read.

[Severity: High]
This is a pre-existing issue, but does super_90_load() completely miss
bounds validation of this_disk.number when the superblock is loaded?

drivers/md/md.c:super_90_load() {
    ...
    rdev->desc_nr = sb->this_disk.number;
    ...
}

When a block device with a crafted version 0.90 superblock is discovered
and assembled, super_90_load() blindly assigns this field without ensuring
it is less than MD_SB_DISKS. Subsequently, super_90_validate() computes
and dereferences an out-of-bounds pointer:

drivers/md/md.c:super_90_validate() {
    ...
    if (sb->disks[rdev->desc_nr].state & (
                (1<<MD_DISK_SYNC) | (1 << MD_DISK_ACTIVE)))
        ...
    desc = sb->disks + rdev->desc_nr;
    if (desc->state & (1<<MD_DISK_FAULTY))
        ...
}

For large values, this dereferences a pointer significantly past the
allocated 4KB superblock page, hitting unmapped memory and causing a kernel
panic. Can bounds validation be added to super_90_load() to prevent this
denial-of-service vector?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913233717.464321-1-aadityakansal390@gmail.com?part=1

[PATCH] md: add max_disks bound check in older version

[Aaditya Kansal]

#syz test

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 680b34a63cb3..f5fce41637f1 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -1693,6 +1693,12 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
 			desc_nr = rdev2->raid_disk;
 		else
 			desc_nr = next_spare++;
+
+		if (desc_nr >= MD_SB_DISKS) {
+			pr_warn("md: raid_disks = %d exceeds max_disks = %d for version 0.90\n",
+					desc_nr, MD_SB_DISKS);
+			continue;
+		}
 		rdev2->desc_nr = desc_nr;
 		d = &sb->disks[rdev2->desc_nr];
 		nr_disks++;
@@ -1722,7 +1728,7 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
 			d->state |= (1<<MD_DISK_FAILFAST);
 	}
 	/* now set the "removed" and "faulty" bits on any missing devices */
-	for (i=0 ; i < mddev->raid_disks ; i++) {
+	for (i = 0; i < mddev->raid_disks && i < MD_SB_DISKS; i++) {
 		mdp_disk_t *d = &sb->disks[i];
 		if (d->state == 0 && d->number == 0) {
 			d->number = i;
--
2.55.0

Re: [PATCH] md: add max_disks bound check in older version

[syzbot]

> #syz test

"" does not look like a valid git branch or commit.

>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 680b34a63cb3..f5fce41637f1 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -1693,6 +1693,12 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
>  			desc_nr = rdev2->raid_disk;
>  		else
>  			desc_nr = next_spare++;
> +
> +		if (desc_nr >= MD_SB_DISKS) {
> +			pr_warn("md: raid_disks = %d exceeds max_disks = %d for version 0.90\n",
> +					desc_nr, MD_SB_DISKS);
> +			continue;
> +		}
>  		rdev2->desc_nr = desc_nr;
>  		d = &sb->disks[rdev2->desc_nr];
>  		nr_disks++;
> @@ -1722,7 +1728,7 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
>  			d->state |= (1<<MD_DISK_FAILFAST);
>  	}
>  	/* now set the "removed" and "faulty" bits on any missing devices */
> -	for (i=0 ; i < mddev->raid_disks ; i++) {
> +	for (i = 0; i < mddev->raid_disks && i < MD_SB_DISKS; i++) {
>  		mdp_disk_t *d = &sb->disks[i];
>  		if (d->state == 0 && d->number == 0) {
>  			d->number = i;
> --
> 2.55.0
>

Re: [PATCH] md: add max_disks bound check in older version

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Skipping disk descriptor assignment via `continue` leaves `rdev->desc_nr` unhandled, causing out-of-bounds array reads or silent metadata corruption when assigning `sb->this_disk`.
--

commit c2add8f93f69d601b2a3935bff10c239b5018489
Author: Aaditya Kansal <aadityakansal390@gmail.com>

md: add max_disks bound check in older version

This commit adds a bounds check to prevent raid_disks from exceeding
the maximum allowed disks for version 0.90 superblocks. It prints a warning
and skips processing for devices that exceed this limit.

> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 680b34a63cb3d..f5fce41637f12 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -1693,6 +1693,12 @@ static void super_90_sync(struct mddev *mddev, struct md_rdev *rdev)
>  			desc_nr = rdev2->raid_disk;
>  		else
>  			desc_nr = next_spare++;
> +
> +		if (desc_nr >= MD_SB_DISKS) {
> +			pr_warn("md: raid_disks = %d exceeds max_disks = %d for version 0.90\n",
> +					desc_nr, MD_SB_DISKS);
> +			continue;
> +		}

[Severity: High]
Does skipping the disk descriptor assignment here leave the descriptor number
unhandled?

If an array has enough devices such that a newly added spare reaches
MD_SB_DISKS, this continue statement skips setting the descriptor number.
Since new devices are initialized with a value of -1, it remains -1.

After the loop, the descriptor is used unconditionally:

drivers/md/md.c:super_90_sync() {
    ...
    sb->this_disk = sb->disks[rdev->desc_nr];
    sb->sb_csum = calc_sb_csum(sb);
}

Can this lead to an out-of-bounds array read if rdev->desc_nr is negative or
invalid?

This is a pre-existing issue, but super_90_validate() blindly uses the
descriptor number read from the on-disk superblock to index the disks array:

drivers/md/md.c:super_90_validate() {
    ...
    if (sb->disks[rdev->desc_nr].state & (
    ...
}

If the bounds are not strictly enforced, could a crafted disk image trigger
an out-of-bounds read there as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913234627.465492-1-aadityakansal390@gmail.com?part=1