linux-kernel - Re: ubiblock: null pointer dereference using scatterlist in work

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]

Message-ID: <260741266.3681.1689591789332.JavaMail.zimbra@nod.at>
Date:   Mon, 17 Jul 2023 13:03:09 +0200 (CEST)
From:   Richard Weinberger <richard@....at>
To:     Stephan Wurm <stephan.wurm@...berle.de>
Cc:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Johannes Eigner <johannes.eigner@...berle.de>
Subject: Re: ubiblock: null pointer dereference using scatterlist in
 work_queue

Stephan,

----- Ursprüngliche Mail -----
> Von: "Stephan Wurm" <stephan.wurm@...berle.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