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;
Date:   Mon, 17 Jul 2023 13:03:09 +0200 (CEST)
From:   Richard Weinberger <richard@nod.at>
To:     Stephan Wurm <stephan.wurm@a-eberle.de>
Cc:     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>,
        Johannes Eigner <johannes.eigner@a-eberle.de>
Message-ID: <260741266.3681.1689591789332.JavaMail.zimbra@nod.at>
In-Reply-To: <ZLUXruUkYMrPK+GQ@PC-LX-Wurm>
References: <ZLT2qEYjaWgSpRD6@PC-LX-Wurm> <736980270.3262.1689586950735.JavaMail.zimbra@nod.at> <ZLUXruUkYMrPK+GQ@PC-LX-Wurm>
Subject: Re: ubiblock: null pointer dereference using scatterlist in
 work_queue
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Thread-Topic: ubiblock: null pointer dereference using scatterlist in work_queue
Thread-Index: ss6EAmPjKXAVOTJ0bHjviSj8oPd3/Q==
Precedence: bulk

Stephan,

----- Ursprüngliche Mail -----
> Von: "Stephan Wurm" <stephan.wurm@a-eberle.de>
>> So reading from ubiblock works as long you don't access it via dm-verity?
>> How about other stacked devices such as dmcrypt?
> 
> We did not check other stacked devices, but we'll give this a try.

Please apply this patch too:

diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index 75eaecc8639f0..795e2d0f61086 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -304,7 +304,7 @@ static void ubiblock_do_work(struct work_struct *work)
         * the number of sg entries is limited to UBI_MAX_SG_COUNT
         * and ubi_read_sg() will check that limit.
         */
-       blk_rq_map_sg(req->q, req, pdu->usgl.sg);
+       ubi_assert(blk_rq_map_sg(req->q, req, pdu->usgl.sg) > 0);
 
        ret = ubiblock_read(pdu);
 

I fear the assert will fail. But let's see. :-D
At least it would explain the NULL deref.
 
>> Did you print the LEB number, read length and offset in ubiblock_read()?
>> Maybe there is a bug related to setting up the correct device geometry
>> and the read request is off.
> Here is some excerpt from another try with KASAN enabled and full debug output:

Hm, we are within bounds. And looks like other reads worked.

>  ==================================================================
>  [  293.343675] BUG: KASAN: null-ptr-deref in ubi_io_read+0x1d4/0x46c
>  [  293.349822] Read of size 1 at addr 00000000 by task kworker/0:3/18
>  [  293.356037]
>  [  293.357551] CPU: 0 PID: 18 Comm: kworker/0:3 Not tainted 6.1.36 #1
>  [  293.363774] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
>  [  293.370331] Workqueue: ubiblock0_2 ubiblock_do_work
>  [  293.375269]  unwind_backtrace from show_stack+0x10/0x14
>  [  293.380557]  show_stack from dump_stack_lvl+0x34/0x48
>  [  293.385668]  dump_stack_lvl from kasan_report+0xb8/0xe8
>  [  293.390956]  kasan_report from ubi_io_read+0x1d4/0x46c
>  [  293.396146]  ubi_io_read from ubi_eba_read_leb+0x3c4/0x5cc
>  [  293.401686]  ubi_eba_read_leb from ubi_eba_read_leb_sg+0x84/0x1f8
>  [  293.407831]  ubi_eba_read_leb_sg from ubi_leb_read_sg+0xb4/0x110

Can you please double check whether the very first call to ubi_eba_read_leb_sg()
fails or a later one?

Thanks,
//richard