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
#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 <redacted>
---
drivers/md/md.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
@@ -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;--
"" does not look like a valid git branch or commit.
quoted hunk
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 <redacted>
---
drivers/md/md.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
@@ -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;--
@@ -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;--
@@ -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;--
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 [off-list ref]
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.
[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
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 [off-list ref]
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.
[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