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>
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 <[email protected]> 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>
Yu Hao,
----- Ursprüngliche Mail -----
> Von: "Yu Hao" <[email protected]>
>> 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
Hi
> Yu Hao,
>
> ----- Ursprüngliche Mail -----
>> Von: "Yu Hao" <[email protected]>
>>> 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?
Hi,
On Wed, Apr 19, 2023 at 9:49 PM Zhihao Cheng <[email protected]> wrote:
>
> Hi
> > Yu Hao,
> >
> > ----- Ursprüngliche Mail -----
> >> Von: "Yu Hao" <[email protected]>
> >>> 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.
----- 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
On Thu, Apr 20, 2023 at 10:33 AM Richard Weinberger <[email protected]> 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
>
----- 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
在 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
----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <[email protected]>
>>> 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
在 2023/4/23 16:02, Richard Weinberger 写道:
> ----- Ursprüngliche Mail -----
>> Von: "chengzhihao1" <[email protected]>
>>>> 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?
Are kernels prior to version 6.2 affected by this issue?
On Sun, 23 Apr 2023, Zhihao Cheng wrote:
> 在 2023/4/23 16:02, Richard Weinberger 写道:
> > ----- Ursprüngliche Mail -----
> > > Von: "chengzhihao1" <[email protected]>
> > > > > 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 [李琼斯]
----- Ursprüngliche Mail -----
> Von: "Lee Jones" <[email protected]>
> 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
----- Ursprüngliche Mail -----
> Von: "Lee Jones" <[email protected]>
> Excellent, thanks.
>
> I'd like to track it. What's the subject please?
"ubi: Refuse attaching if mtd's erasesize is 0"
Thanks,
//richard
On Mon, 02 Oct 2023, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Von: "Lee Jones" <[email protected]>
> > 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 [李琼斯]
On Mon, 02 Oct 2023, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Von: "Lee Jones" <[email protected]>
> > 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 [李琼斯]