linux-kernel - Re: BUG: divide error in ubi_attach_mtd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Apr 2023 10:27:32 -0700
From:   Yu Hao <yhao016@....edu>
To:     Zhihao Cheng <chengzhihao1@...wei.com>
Cc:     Richard Weinberger <richard@....at>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: BUG: divide error in ubi_attach_mtd_dev

Hi,

On Wed, Apr 19, 2023 at 9:49 PM Zhihao Cheng <chengzhihao1@...wei.com> wrote:
>
> Hi
> > Yu Hao,
> >
> > ----- Ursprüngliche Mail -----
> >> Von: "Yu Hao" <yhao016@....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.