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] [day] [month] [year] [list]

Message-Id: <5234146D-E9D8-4D05-95F0-D3308F9CAFFD@mac.com>
Date: Mon, 24 Jun 2024 13:00:08 -0600
From: Gagan Sidhu <broly@....com>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Zhihao Cheng <chengzhihao1@...wei.com>,
 Richard Weinberger <richard@....at>,
 ZhaoLong Wang <wangzhaolong1@...wei.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

actually the issue was resolved. we are discussing unexpected behaviour when both MTD_UBI_GLUEBI and MTD_UBI_BLOCK are enabled.

disabling MTD_UBI_GLUEBI fixed my issue, and everything mounted as expected afterwards.

the question was why ubiblock0_0 was not being mounted when MTD_UBI_GLUEBI was enabled, and the evidence suggested it was somehow being assigned the label MTD_UBIVOLUME

but if no one cares that’s fine lol

Thanks,
Gagan

> On Jun 22, 2024, at 3:07 PM, Daniel Golle <daniel@...rotopia.org> wrote:
> 
> On Fri, Jun 21, 2024 at 08:43:47PM -0600, Gagan Sidhu wrote:
>> [...]
>> GLUEBI should be operating on the /dev/mtdblockX device and not ubiblock0_0 and thus the boot procedure created by openwrt should be unaffected.
>> 
>> at least that’s how i would understand the situation if each are creating their own devices.
>> 
>> we need to figure out a solution or maybe master rich should end our ongoing discussion because technically “it’s not mainline” and we’re probably boring the recipients.
> 
> I've suggested a simple solution here:
> 
> https://lkml.org/lkml/2024/6/17/1602
> 
> You could try that and let us know if it resolves the issue for you.