BUG: divide error in ubi_attach_mtd_dev

BUG: divide error in ubi_attach_mtd_dev

[Yu Hao]

Hello,

We found the following issue using syzkaller on Linux v6.2.0.
The full report:
https://gist.github.com/ZHYfeng/a3e3ff2bdfea5ed5de5475f0b54d55cb

The brief report is below:

ubi: mtd0 is already attached to ubi0
ubi7: attaching mtd147
divide error: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 20023 Comm: syz-executor.0 Not tainted 6.2.0 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:mtd_div_by_eb include/linux/mtd/mtd.h:580 [inline]
RIP: 0010:io_init drivers/mtd/ubi/build.c:620 [inline]
RIP: 0010:ubi_attach_mtd_dev+0x77f/0x2fe0 drivers/mtd/ubi/build.c:955
Code: fc ff df 48 c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38
d0 7c 08 84 d2 0f 85 1f 25 00 00 41 8b 4c 24 10 48 89 d8 31 d2 <48> f7
f1 48 89 c3 e8 b6 f3 1b fc 48 8d 85 40 17 00 00 48 89 c2 48
RSP: 0018:ffffc9000be0fd30 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff888047a49d40 RDI: 0000000000000002
RBP: ffff888024e1c000 R08: 0000000000000016 R09: fffff520017c1f47
R10: ffffc9000be0fa37 R11: fffff520017c1f46 R12: ffff88806545a000
R13: 0000000000000000 R14: ffff88806545a010 R15: 0000000000000007
FS:  00007fd45e85c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f64aeef53a4 CR3: 000000004f39a000 CR4: 0000000000350ef0
Call Trace:
 <TASK>
 ctrl_cdev_ioctl+0x303/0x3a0 drivers/mtd/ubi/cdev.c:1043
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x198/0x210 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fd45d6902fd
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 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 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd45e85bc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fd45d7bbf60 RCX: 00007fd45d6902fd
RDX: 0000000020000000 RSI: 0000000040186f40 RDI: 0000000000000005
RBP: 00007fd45d6fec89 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff676814bf R14: 00007fff67681670 R15: 00007fd45e85bdc0
 </TASK>

Re: BUG: divide error in ubi_attach_mtd_dev

[Yu Hao]

Sorry that there is a mistake for the full report.
It should be https://gist.github.com/ZHYfeng/ae66bf8167bc341d3753af00e9902b1a

On Mon, Apr 17, 2023 at 10:10 PM Yu Hao <yhao016@ucr.edu> wrote:
>
> Hello,
>
> We found the following issue using syzkaller on Linux v6.2.0.
> The full report:
> https://gist.github.com/ZHYfeng/a3e3ff2bdfea5ed5de5475f0b54d55cb
>
> The brief report is below:
>
> ubi: mtd0 is already attached to ubi0
> ubi7: attaching mtd147
> divide error: 0000 [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 20023 Comm: syz-executor.0 Not tainted 6.2.0 #6
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> RIP: 0010:mtd_div_by_eb include/linux/mtd/mtd.h:580 [inline]
> RIP: 0010:io_init drivers/mtd/ubi/build.c:620 [inline]
> RIP: 0010:ubi_attach_mtd_dev+0x77f/0x2fe0 drivers/mtd/ubi/build.c:955
> Code: fc ff df 48 c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38
> d0 7c 08 84 d2 0f 85 1f 25 00 00 41 8b 4c 24 10 48 89 d8 31 d2 <48> f7
> f1 48 89 c3 e8 b6 f3 1b fc 48 8d 85 40 17 00 00 48 89 c2 48
> RSP: 0018:ffffc9000be0fd30 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffff888047a49d40 RDI: 0000000000000002
> RBP: ffff888024e1c000 R08: 0000000000000016 R09: fffff520017c1f47
> R10: ffffc9000be0fa37 R11: fffff520017c1f46 R12: ffff88806545a000
> R13: 0000000000000000 R14: ffff88806545a010 R15: 0000000000000007
> FS:  00007fd45e85c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f64aeef53a4 CR3: 000000004f39a000 CR4: 0000000000350ef0
> Call Trace:
>  <TASK>
>  ctrl_cdev_ioctl+0x303/0x3a0 drivers/mtd/ubi/cdev.c:1043
>  vfs_ioctl fs/ioctl.c:51 [inline]
>  __do_sys_ioctl fs/ioctl.c:870 [inline]
>  __se_sys_ioctl fs/ioctl.c:856 [inline]
>  __x64_sys_ioctl+0x198/0x210 fs/ioctl.c:856
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7fd45d6902fd
> Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 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 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fd45e85bc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007fd45d7bbf60 RCX: 00007fd45d6902fd
> RDX: 0000000020000000 RSI: 0000000040186f40 RDI: 0000000000000005
> RBP: 00007fd45d6fec89 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fff676814bf R14: 00007fff67681670 R15: 00007fd45e85bdc0
>  </TASK>

Re: BUG: divide error in ubi_attach_mtd_dev

[Richard Weinberger]

Yu Hao,

----- Ursprüngliche Mail -----
> Von: "Yu Hao" <yhao016@ucr.edu>
>> ubi: mtd0 is already attached to ubi0
>> ubi7: attaching mtd147
>> divide error: 0000 [#1] PREEMPT SMP KASAN
>> CPU: 0 PID: 20023 Comm: syz-executor.0 Not tainted 6.2.0 #6
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.13.0-1ubuntu1.1 04/01/2014
>> RIP: 0010:mtd_div_by_eb include/linux/mtd/mtd.h:580 [inline]
>> RIP: 0010:io_init drivers/mtd/ubi/build.c:620 [inline]
>> RIP: 0010:ubi_attach_mtd_dev+0x77f/0x2fe0 drivers/mtd/ubi/build.c:955
>> Code: fc ff df 48 c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38
>> d0 7c 08 84 d2 0f 85 1f 25 00 00 41 8b 4c 24 10 48 89 d8 31 d2 <48> f7
>> f1 48 89 c3 e8 b6 f3 1b fc 48 8d 85 40 17 00 00 48 89 c2 48
>> RSP: 0018:ffffc9000be0fd30 EFLAGS: 00010246
>> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: ffff888047a49d40 RDI: 0000000000000002
>> RBP: ffff888024e1c000 R08: 0000000000000016 R09: fffff520017c1f47
>> R10: ffffc9000be0fa37 R11: fffff520017c1f46 R12: ffff88806545a000
>> R13: 0000000000000000 R14: ffff88806545a010 R15: 0000000000000007
>> FS:  00007fd45e85c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f64aeef53a4 CR3: 000000004f39a000 CR4: 0000000000350ef0
>> Call Trace:
>>  <TASK>
>>  ctrl_cdev_ioctl+0x303/0x3a0 drivers/mtd/ubi/cdev.c:1043

What kind of MTD you attaching?
Has it erasesize 0?

Thanks,
//richard

Re: BUG: divide error in ubi_attach_mtd_dev

[Zhihao Cheng]

Hi
> Yu Hao,
> 
> ----- Ursprüngliche Mail -----
>> Von: "Yu Hao" <yhao016@ucr.edu>
>>> ubi: mtd0 is already attached to ubi0
>>> ubi7: attaching mtd147
>>> divide error: 0000 [#1] PREEMPT SMP KASAN
>>> CPU: 0 PID: 20023 Comm: syz-executor.0 Not tainted 6.2.0 #6
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>> 1.13.0-1ubuntu1.1 04/01/2014
>>> RIP: 0010:mtd_div_by_eb include/linux/mtd/mtd.h:580 [inline]
>>> RIP: 0010:io_init drivers/mtd/ubi/build.c:620 [inline]
>>> RIP: 0010:ubi_attach_mtd_dev+0x77f/0x2fe0 drivers/mtd/ubi/build.c:955
>>> Code: fc ff df 48 c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38
>>> d0 7c 08 84 d2 0f 85 1f 25 00 00 41 8b 4c 24 10 48 89 d8 31 d2 <48> f7
>>> f1 48 89 c3 e8 b6 f3 1b fc 48 8d 85 40 17 00 00 48 89 c2 48
>>> RSP: 0018:ffffc9000be0fd30 EFLAGS: 00010246
>>> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
>>> RDX: 0000000000000000 RSI: ffff888047a49d40 RDI: 0000000000000002
>>> RBP: ffff888024e1c000 R08: 0000000000000016 R09: fffff520017c1f47
>>> R10: ffffc9000be0fa37 R11: fffff520017c1f46 R12: ffff88806545a000
>>> R13: 0000000000000000 R14: ffff88806545a010 R15: 0000000000000007
>>> FS:  00007fd45e85c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 00007f64aeef53a4 CR3: 000000004f39a000 CR4: 0000000000350ef0
>>> Call Trace:
>>>   <TASK>
>>>   ctrl_cdev_ioctl+0x303/0x3a0 drivers/mtd/ubi/cdev.c:1043
> 
> What kind of MTD you attaching?
> Has it erasesize 0?
> 

Yes, I agree with Richard's point, I guess UBI got an mtd device with 
zero erasesize.


  568 static inline uint32_t mtd_div_by_eb(uint64_t sz, struct mtd_info 
*mtd)
  569 {
  570         if (mtd->erasesize_shift)       // erasesize_shift is 0
  571                 return sz >> mtd->erasesize_shift;
  572         do_div(sz, mtd->erasesize);    // erasesize is 0 too
  573         return sz;
  574 }

Yu Hao, how do you find the problem, by syzkaller? Can you provide the 
reproducing program or reproducing log?

Re: BUG: divide error in ubi_attach_mtd_dev

[Yu Hao]

Hi,

On Wed, Apr 19, 2023 at 9:49 PM Zhihao Cheng <chengzhihao1@huawei.com> wrote:
>
> Hi
> > Yu Hao,
> >
> > ----- Ursprüngliche Mail -----
> >> Von: "Yu Hao" <yhao016@ucr.edu>
> >>> ubi: mtd0 is already attached to ubi0
> >>> ubi7: attaching mtd147
> >>> divide error: 0000 [#1] PREEMPT SMP KASAN
> >>> CPU: 0 PID: 20023 Comm: syz-executor.0 Not tainted 6.2.0 #6
> >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> >>> 1.13.0-1ubuntu1.1 04/01/2014
> >>> RIP: 0010:mtd_div_by_eb include/linux/mtd/mtd.h:580 [inline]
> >>> RIP: 0010:io_init drivers/mtd/ubi/build.c:620 [inline]
> >>> RIP: 0010:ubi_attach_mtd_dev+0x77f/0x2fe0 drivers/mtd/ubi/build.c:955
> >>> Code: fc ff df 48 c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38
> >>> d0 7c 08 84 d2 0f 85 1f 25 00 00 41 8b 4c 24 10 48 89 d8 31 d2 <48> f7
> >>> f1 48 89 c3 e8 b6 f3 1b fc 48 8d 85 40 17 00 00 48 89 c2 48
> >>> RSP: 0018:ffffc9000be0fd30 EFLAGS: 00010246
> >>> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> >>> RDX: 0000000000000000 RSI: ffff888047a49d40 RDI: 0000000000000002
> >>> RBP: ffff888024e1c000 R08: 0000000000000016 R09: fffff520017c1f47
> >>> R10: ffffc9000be0fa37 R11: fffff520017c1f46 R12: ffff88806545a000
> >>> R13: 0000000000000000 R14: ffff88806545a010 R15: 0000000000000007
> >>> FS:  00007fd45e85c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
> >>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>> CR2: 00007f64aeef53a4 CR3: 000000004f39a000 CR4: 0000000000350ef0
> >>> Call Trace:
> >>>   <TASK>
> >>>   ctrl_cdev_ioctl+0x303/0x3a0 drivers/mtd/ubi/cdev.c:1043
> >
> > What kind of MTD you attaching?
> > Has it erasesize 0?
> >
>
> Yes, I agree with Richard's point, I guess UBI got an mtd device with
> zero erasesize.
>

The kernel is in qemu. We find that the `mtd` is from
`mtd = get_mtd_device(NULL, req.mtd_num);` in function `ctrl_cdev_ioctl`.
 And we are still trying to figure out what MTD is.

>
>   568 static inline uint32_t mtd_div_by_eb(uint64_t sz, struct mtd_info
> *mtd)
>   569 {
>   570         if (mtd->erasesize_shift)       // erasesize_shift is 0
>   571                 return sz >> mtd->erasesize_shift;
>   572         do_div(sz, mtd->erasesize);    // erasesize is 0 too
>   573         return sz;
>   574 }
>
> Yu Hao, how do you find the problem, by syzkaller? Can you provide the
> reproducing program or reproducing log?

We find this by syzkaller with customized syscall descriptions.
There is not any reproducing program now.

Re: BUG: divide error in ubi_attach_mtd_dev

[Richard Weinberger]

----- Ursprüngliche Mail -----
> The kernel is in qemu. We find that the `mtd` is from
> `mtd = get_mtd_device(NULL, req.mtd_num);` in function `ctrl_cdev_ioctl`.
> And we are still trying to figure out what MTD is.

Can you please share the qemu command line?

Within Linux you can query /proc/mtd or /sys/class/mtd/
to get infos about the MTD in question.

Thanks,
//richard
 

Re: BUG: divide error in ubi_attach_mtd_dev

[Yu Hao]

On Thu, Apr 20, 2023 at 10:33 AM Richard Weinberger <richard@nod.at> wrote:
>
> ----- Ursprüngliche Mail -----
> > The kernel is in qemu. We find that the `mtd` is from
> > `mtd = get_mtd_device(NULL, req.mtd_num);` in function `ctrl_cdev_ioctl`.
> > And we are still trying to figure out what MTD is.
>
> Can you please share the qemu command line?
>

qemu-system-x86_64 -m 2G -smp 2 -kernel
/home/test/Workspace/SyzGen/linux-distro/linux-6.2-debug/arch/x86/boot/bzImage
-append “console=ttyS0 root=/dev/sda net.ifnames=0” -hda
/home/test/Workspace/SyzGen/linux-distro/image/stretch.img -chardev
socket,id=SOCKSYZ,server=on,nowait,host=localhost,port=54640 -mon
chardev=SOCKSYZ,mode=control -device virtio-rng-pci -device
e1000,netdev=net0 -netdev
user,id=net0,restrict=on,hostfwd=tcp:127.0.0.1:11760-:22 -display none
-serial stdio -cpu host,migratable=off -no-reboot -name VM -snapshot
-enable-kvm

> Within Linux you can query /proc/mtd or /sys/class/mtd/
> to get infos about the MTD in question.
>

Thanks for the hints. We find that this is a “mtdram test device”.

root@syzkaller:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 “mtdram test device”

> Thanks,
> //richard
>

Re: BUG: divide error in ubi_attach_mtd_dev

[Richard Weinberger]

----- Ursprüngliche Mail -----
>> Can you please share the qemu command line?
> qemu-system-x86_64 -m 2G -smp 2 -kernel
> /home/test/Workspace/SyzGen/linux-distro/linux-6.2-debug/arch/x86/boot/bzImage
> -append “console=ttyS0 root=/dev/sda net.ifnames=0” -hda
> /home/test/Workspace/SyzGen/linux-distro/image/stretch.img -chardev
> socket,id=SOCKSYZ,server=on,nowait,host=localhost,port=54640 -mon
> chardev=SOCKSYZ,mode=control -device virtio-rng-pci -device
> e1000,netdev=net0 -netdev
> user,id=net0,restrict=on,hostfwd=tcp:127.0.0.1:11760-:22 -display none
> -serial stdio -cpu host,migratable=off -no-reboot -name VM -snapshot
> -enable-kvm
> 
>> Within Linux you can query /proc/mtd or /sys/class/mtd/
>> to get infos about the MTD in question.
>>
> 
> Thanks for the hints. We find that this is a “mtdram test device”.
> 
> root@syzkaller:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00020000 00001000 “mtdram test device”

Hmm, mtdram should be fine, erasesize is not zero.

Thanks,
//richard

Re: BUG: divide error in ubi_attach_mtd_dev

[Zhihao Cheng]

在 2023/4/21 4:36, Richard Weinberger 写道:
> ----- Ursprüngliche Mail -----
>>> Can you please share the qemu command line?
>> qemu-system-x86_64 -m 2G -smp 2 -kernel
>> /home/test/Workspace/SyzGen/linux-distro/linux-6.2-debug/arch/x86/boot/bzImage
>> -append “console=ttyS0 root=/dev/sda net.ifnames=0” -hda
>> /home/test/Workspace/SyzGen/linux-distro/image/stretch.img -chardev
>> socket,id=SOCKSYZ,server=on,nowait,host=localhost,port=54640 -mon
>> chardev=SOCKSYZ,mode=control -device virtio-rng-pci -device
>> e1000,netdev=net0 -netdev
>> user,id=net0,restrict=on,hostfwd=tcp:127.0.0.1:11760-:22 -display none
>> -serial stdio -cpu host,migratable=off -no-reboot -name VM -snapshot
>> -enable-kvm
>>
>>> Within Linux you can query /proc/mtd or /sys/class/mtd/
>>> to get infos about the MTD in question.
>>>
>>
>> Thanks for the hints. We find that this is a “mtdram test device”.
>>
>> root@syzkaller:~# cat /proc/mtd
>> dev:    size   erasesize  name
>> mtd0: 00020000 00001000 “mtdram test device”
> 
> Hmm, mtdram should be fine, erasesize is not zero.
> 

I guess the zero-erasesize mtd device is dynamically generated in 
runtime, after looking through the code, I find erasesize is 
initiallized in specific flash driver and it won't be updated later(eg. 
ioctl\sysctl). And some mtd devices may have zero erasesize, eg. 
drivers/mtd/devices/mchp23k256.c[1]. Unfortunately, I don't know how to 
load/simulate this mtd, maybe it requires a real device? If we load this 
mtd device as ubi, it will trigger the problem?


[1] https://cloud.tencent.com/developer/ask/sof/114616431

Re: BUG: divide error in ubi_attach_mtd_dev

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1@huawei.com>
>>> root@syzkaller:~# cat /proc/mtd
>>> dev:    size   erasesize  name
>>> mtd0: 00020000 00001000 “mtdram test device”
>> 
>> Hmm, mtdram should be fine, erasesize is not zero.
>> 
> 
> I guess the zero-erasesize mtd device is dynamically generated in
> runtime, after looking through the code, I find erasesize is
> initiallized in specific flash driver and it won't be updated later(eg.
> ioctl\sysctl). And some mtd devices may have zero erasesize, eg.
> drivers/mtd/devices/mchp23k256.c[1]. Unfortunately, I don't know how to
> load/simulate this mtd, maybe it requires a real device? If we load this
> mtd device as ubi, it will trigger the problem?

Indeed. I guess qemu can emulate such chips.
So better fix UBI to reject attaching of mtd's with erasesize being 0.
(Please note, we cannot test for MTD_NO_ERASE, this one means there is no
erase method).

Thanks,
//richard

Re: BUG: divide error in ubi_attach_mtd_dev

[Zhihao Cheng]

在 2023/4/23 16:02, Richard Weinberger 写道:
> ----- Ursprüngliche Mail -----
>> Von: "chengzhihao1" <chengzhihao1@huawei.com>
>>>> root@syzkaller:~# cat /proc/mtd
>>>> dev:    size   erasesize  name
>>>> mtd0: 00020000 00001000 “mtdram test device”
>>>
>>> Hmm, mtdram should be fine, erasesize is not zero.
>>>
>>
>> I guess the zero-erasesize mtd device is dynamically generated in
>> runtime, after looking through the code, I find erasesize is
>> initiallized in specific flash driver and it won't be updated later(eg.
>> ioctl\sysctl). And some mtd devices may have zero erasesize, eg.
>> drivers/mtd/devices/mchp23k256.c[1]. Unfortunately, I don't know how to
>> load/simulate this mtd, maybe it requires a real device? If we load this
>> mtd device as ubi, it will trigger the problem?
> 
> Indeed. I guess qemu can emulate such chips.
> So better fix UBI to reject attaching of mtd's with erasesize being 0.
> (Please note, we cannot test for MTD_NO_ERASE, this one means there is no
> erase method).

Phram is an exception, it has erase function but is set flag 
'MTD_CAP_RAM'. May I interpret 'MTD_NO_ERASE' as erase function is not 
necessary?

Re: BUG: divide error in ubi_attach_mtd_dev

[admamiac]

Are kernels prior to version 6.2 affected by this issue?

Re: BUG: divide error in ubi_attach_mtd_dev

[Lee Jones]

On Sun, 23 Apr 2023, Zhihao Cheng wrote:

> 在 2023/4/23 16:02, Richard Weinberger 写道:
> > ----- Ursprüngliche Mail -----
> > > Von: "chengzhihao1" <chengzhihao1@huawei.com>
> > > > > root@syzkaller:~# cat /proc/mtd
> > > > > dev:    size   erasesize  name
> > > > > mtd0: 00020000 00001000 “mtdram test device”
> > > > 
> > > > Hmm, mtdram should be fine, erasesize is not zero.
> > > > 
> > > 
> > > I guess the zero-erasesize mtd device is dynamically generated in
> > > runtime, after looking through the code, I find erasesize is
> > > initiallized in specific flash driver and it won't be updated later(eg.
> > > ioctl\sysctl). And some mtd devices may have zero erasesize, eg.
> > > drivers/mtd/devices/mchp23k256.c[1]. Unfortunately, I don't know how to
> > > load/simulate this mtd, maybe it requires a real device? If we load this
> > > mtd device as ubi, it will trigger the problem?
> > 
> > Indeed. I guess qemu can emulate such chips.
> > So better fix UBI to reject attaching of mtd's with erasesize being 0.
> > (Please note, we cannot test for MTD_NO_ERASE, this one means there is no
> > erase method).
> 
> Phram is an exception, it has erase function but is set flag 'MTD_CAP_RAM'.
> May I interpret 'MTD_NO_ERASE' as erase function is not necessary?

For better or worse, someone has applied to have this report associated
with a CVE which means a bunch of companies and individuals are going to
be tracking it.

What is the current status please?

Is this deemed to be a real issue?

Did the report culminate in a posted patch?

Any help would be gratefully received.

-- 
Lee Jones [李琼斯]

Re: BUG: divide error in ubi_attach_mtd_dev

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Lee Jones" <lee@kernel.org>
> For better or worse, someone has applied to have this report associated
> with a CVE which means a bunch of companies and individuals are going to
> be tracking it.
> 
> What is the current status please?

I was about to answer that the patch is upstream, but it's only in linux-next. :-S
After lunch I'll immediately send a PR. I messed up due to too much traveling
the last months.
 
> Is this deemed to be a real issue?

I don't think so. Only the real root can install new MTD devices and run UBI attach.

> Did the report culminate in a posted patch?

Yes. As I said a patch is in next.

Thanks,
//richard

Re: BUG: divide error in ubi_attach_mtd_dev

[Lee Jones]

On Mon, 02 Oct 2023, Richard Weinberger wrote:

> ----- Ursprüngliche Mail -----
> > Von: "Lee Jones" <lee@kernel.org>
> > For better or worse, someone has applied to have this report associated
> > with a CVE which means a bunch of companies and individuals are going to
> > be tracking it.
> > 
> > What is the current status please?
> 
> I was about to answer that the patch is upstream, but it's only in linux-next. :-S
> After lunch I'll immediately send a PR. I messed up due to too much traveling
> the last months.
>  
> > Is this deemed to be a real issue?
> 
> I don't think so. Only the real root can install new MTD devices and run UBI attach.
> 
> > Did the report culminate in a posted patch?
> 
> Yes. As I said a patch is in next.

Excellent, thanks.

I'd like to track it.  What's the subject please?

-- 
Lee Jones [李琼斯]

Re: BUG: divide error in ubi_attach_mtd_dev

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Lee Jones" <lee@kernel.org>
> Excellent, thanks.
> 
> I'd like to track it.  What's the subject please?

"ubi: Refuse attaching if mtd's erasesize is 0"
 
Thanks,
//richard

Re: BUG: divide error in ubi_attach_mtd_dev

[Lee Jones]

On Mon, 02 Oct 2023, Richard Weinberger wrote:

> ----- Ursprüngliche Mail -----
> > Von: "Lee Jones" <lee@kernel.org>
> > Excellent, thanks.
> > 
> > I'd like to track it.  What's the subject please?
> 
> "ubi: Refuse attaching if mtd's erasesize is 0"

That's great, thank you Richard.

-- 
Lee Jones [李琼斯]