Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CA+UBctD_w=75wChmePZHp7KsBSNPWYGDBtzHPRPPtaFoqhGvXA@mail.gmail.com>
 <CA+UBctDsHRpkLG5ppdiuV8Msn4Dx-ZJ2xDrxfa48VMb7ZE+xBA@mail.gmail.com>
 <687864524.118195.1681799447034.JavaMail.zimbra@nod.at> <ff419c45-7d76-0219-a598-f6f4d081e29c@huawei.com>
In-Reply-To: <ff419c45-7d76-0219-a598-f6f4d081e29c@huawei.com>
From:   Yu Hao <yhao016@ucr.edu>
Date:   Thu, 20 Apr 2023 10:27:32 -0700
Message-ID: <CA+UBctBVHouL-3rM3zKYLpk01fXFvCpBnU7EpSRVdGW7cEjcJQ@mail.gmail.com>
Subject: Re: BUG: divide error in ubi_attach_mtd_dev
To:     Zhihao Cheng <chengzhihao1@huawei.com>
Cc:     Richard Weinberger <richard@nod.at>,
        Miquel Raynal <miquel.raynal@bootlin.com>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        linux-mtd <linux-mtd@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,

On Wed, Apr 19, 2023 at 9:49=E2=80=AFPM Zhihao Cheng <chengzhihao1@huawei.c=
om> wrote:
>
> Hi
> > Yu Hao,
> >
> > ----- Urspr=C3=BCngliche 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> f=
7
> >>> 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:000000000=
0000000
> >>> 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 =3D 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.