linux-kernel - Re: [PATCH v2] ubi: gluebi: Fix NULL pointer dereference caused by ftl notifier

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: <251ae039-9f46-081b-a7ee-fe47de268865@huawei.com>
Date: Tue, 18 Jun 2024 12:03:56 +0800
From: Zhihao Cheng <chengzhihao1@...wei.com>
To: Gagan Sidhu <broly@....com>, Daniel Golle <daniel@...rotopia.org>
CC: Richard Weinberger <richard@....at>, ZhaoLong Wang
	<wangzhaolong1@...wei.com>, dpervushin <dpervushin@...eddedalley.com>,
	linux-kernel <linux-kernel@...r.kernel.org>, linux-mtd
	<linux-mtd@...ts.infradead.org>, Miquel Raynal <miquel.raynal@...tlin.com>,
	Vignesh Raghavendra <vigneshr@...com>, yangerkun <yangerkun@...wei.com>, yi
 zhang <yi.zhang@...wei.com>
Subject: Re: [PATCH v2] ubi: gluebi: Fix NULL pointer dereference caused by
 ftl notifier

在 2024/6/18 6:13, Gagan Sidhu 写道:
Hi,
> spoke to a user, gave him a build without MTD_GLUEBI, restoring changes made by (HAHAHA you are! huawei), it booted fine.
> 

May I have the layers' information about mtd/ubi, you can get it by 
'mtdinfo -a' and 'ubinfo -a' after booting the device.
I guess your device boots from ubiblock0_0. There are two ways loading 
booting device:
1. mtd(nand)
    ubi(holds volume ubi0_0)
    mtd12 (gluebi)
    mtdblock12  (This way is cut by this patch, so mtdblock12 is not 
generated, just like Daniel&Richard analyzed)
2. mtd(nand)
    ubi(holds volume ubi0_0)
    ubiblock0_0

> so we need to think about either deprecating GLUEBI or setting an option in the Kconfig that ensures they are mutually exclusive.
> 
> gluebi is definitely highjacking the block device created by UBI_BLOCK and adding the MTD_UBIVOLUME flag to it.

The gluebi(mtd) and ubiblock could exist on the same UBI volume at the 
same time, but they cannot be opened at the same time. Here is an 
example I tested on the local machine:

                                              ↗ ubiblock0_0
mtd0(nandsim) -> ubi0 (holds volume ubi0_0)
                                              ↘ gluebi(mtd1)

[root@...alhost ~]# ubinfo -a
UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:61
Present UBI devices:            ubi0

ubi0
Volumes count:                           1
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     8192 (1040187392 bytes, 992.0 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  160
Current maximum erase counter value:     2
Minimum input/output unit size:          2048 bytes
Character device major/minor:            246:0
Present volumes:                         0

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        8026 LEBs (1019109376 bytes, 971.8 MiB)
State:       OK
Name:        vol_a
Character device major/minor: 246:1
[root@...alhost ~]# mtdinfo -a
Count of MTD devices:           2
Present MTD devices:            mtd0, mtd1
Sysfs interface supported:      yes

mtd0
Name:                           NAND simulator partition 0
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          8192 (1073741824 bytes, 1024.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

mtd1
Name:                           vol_a
Type:                           ubi
Eraseblock size:                126976 bytes, 124.0 KiB
Amount of eraseblocks:          8026 (1019109376 bytes, 971.8 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
Character device major/minor:   90:2
Bad blocks are allowed:         false
Device is writable:             true

[root@...alhost ~]# lsblk | grep ubi
ubiblock0_0 251:0    0 971.9M  0 disk

> 
> there is no other explanation.
> 
> looks like this was an absolutely amazing exchange that even furthered our understanding of wtf is going on.
> 
> thanks for being a great moderator for MTD rich
> 
> Thanks,
> Gagan