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: <136290141.252319.1718650375432.JavaMail.zimbra@nod.at>
Date: Mon, 17 Jun 2024 20:52:55 +0200 (CEST)
From: Richard Weinberger <richard@....at>
To: Gagan Sidhu <broly@....com>
Cc: ZhaoLong Wang <wangzhaolong1@...wei.com>, 
	chengzhihao1 <chengzhihao1@...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>, 
	daniel@...rotopia.org
Subject: Re: [PATCH v2] ubi: gluebi: Fix NULL pointer dereference caused by
 ftl notifier

[CC'ing Daniel]

----- Ursprüngliche Mail -----
> Von: "Gagan Sidhu" <broly@....com>
> An: "richard" <richard@....at>
> CC: "ZhaoLong Wang" <wangzhaolong1@...wei.com>, "chengzhihao1" <chengzhihao1@...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>
> Gesendet: Montag, 17. Juni 2024 20:46:10
> Betreff: Re: [PATCH v2] ubi: gluebi: Fix NULL pointer dereference caused by ftl notifier

>> On Jun 17, 2024, at 12:32 PM, Richard Weinberger <richard@....at> wrote:
>> 
>> ----- Ursprüngliche Mail -----
>>> Von: "Gagan Sidhu" <broly@....com>
>>>> AFAICT, this log line is not part of the mainline kernel.
>>> 
>>> this is mainline. it’s just not 6.x. it’s 4.14.
>> 
>> I've double checked and disagree.
>> This line comes from:
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/pending-4.14/480-mtd-set-rootfs-to-be-root-dev.patch;h=6cddaf01b75cb58cfb377f568f2c375af87e2f1b;hb=c3bd1321de1e0d814f5cfc4f494f6b2fb1f5133b
> 
> no i know that, that’s the patch i showed you. i meant the rest of it is
> mainline. the patch obviously is not.
>> 
>> In recent OpenWRT kernels I see:
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/pending-5.15/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch;h=266a6331c2acc0f7c17d9ac72f54659d31b56249;hb=HEAD
>> 
>> Looks like in recent versions the patch in question does *not* cause a
>> regression.
> 
> that patch is also applied in my version as well, so i don’t see how this avoids
> the regression.
> 
> https://github.com/torvalds/linux/blob/master/drivers/mtd/mtdcore.c#L774
> 
> mine says "[6.051426] mtd: device 12 (rootfs) set to be root filesystem"
> 
> which is simply the call from drivers/mtd/mtdcore.c
> 
> so the rootfs device is set correctly. it’s just not booting from it.
> 
> the regression comes from having GLUEBI+BLOCK enabled, it seems, are they
> fighting for/operating on the same partition?

I don't know. Let's ask Daniel.

> 
>> 
>>>> (31, 12) would be mtdblock12.
>>>> How does your kernel know that mtdblock12 shall be the rootfs?
>>> 
>>> this is an openwrt approach: https://openwrt.org/docs/techref/filesystems (under
>>> “technical details”, third paragraph)
>>> 
>>> essentially there’s a feature they add to the kernel (via patch) where you can
>>> enable a feature that sets the root device based on the name of the partition.
>> 
>> So, this is all not mainline. :-/
> 
> i did say openwrt at the start, and i think that’s pretty close to mainline as
> it gets.
> 
> sometimes these patches aren’t appropriate to push upstream. this one is not the
> one causing the issue.
> 
> it seems to me that there is a problem with GLUEBI+BLOCK playing together.
> 
> as far as i can see, the setting of the device is being doing by mtdcore.c
> 
> it’s just not working with gluebi and block are enabled, and i need to know
> whether disabling gluebi will allow it to work.
> 
> in other words, is it possible for gluebi to use the partition created by
> ubi_block, and add the MTD_UBIVOLUME flag?

No. UBIBlock works on top of UBI volumes and creates a block device.

We'll sort this out. :)

Thanks,
//richard