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: <3841F21D-CA54-456C-9D9C-F06EEA332A30@mac.com>
Date: Mon, 17 Jun 2024 12:46:10 -0600
From: Gagan Sidhu <broly@....com>
To: Richard Weinberger <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>
Subject: 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?

> 
>>> (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?

> 
>> in this case as long as the volume within your ubi file contains the name
>> “rootfs”, openwrt will follow it as it gets unpacked and set that as the
>> rootdevice for you.
> 
> Thanks,
> //richard