linux-kernel - Re: riscv32 EXT4 splat, 6.8 regression?

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: <887E261B-3C76-4CD9-867B-5D087051D004@dilger.ca>
Date: Sat, 13 Apr 2024 22:16:07 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Nam Cao <namcao@...utronix.de>,
 Björn Töpel <bjorn@...nel.org>,
 linux-fsdevel <linux-fsdevel@...r.kernel.org>,
 Christian Brauner <brauner@...nel.org>,
 Jan Kara <jack@...e.cz>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 linux-riscv@...ts.infradead.org,
 Theodore Ts'o <tytso@....edu>,
 Ext4 Developers List <linux-ext4@...r.kernel.org>,
 Conor Dooley <conor@...nel.org>
Subject: Re: riscv32 EXT4 splat, 6.8 regression?

On Apr 13, 2024, at 8:15 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> 
> On Sat, Apr 13, 2024 at 07:46:03PM -0600, Andreas Dilger wrote:
> 
>> As to whether the 0xfffff000 address itself is valid for riscv32 is
>> outside my realm, but given that RAM is cheap it doesn't seem unlikely
>> to have 4GB+ of RAM and want to use it all.  The riscv32 might consider
>> reserving this page address from allocation to avoid similar issues in
>> other parts of the code, as is done with the NULL/0 page address.
> 
> Not a chance.  *Any* page mapped there is a serious bug on any 32bit
> box.  Recall what ERR_PTR() is...
> 
> On any architecture the virtual addresses in range (unsigned long)-512..
> (unsigned long)-1 must never resolve to valid kernel objects.
> In other words, any kind of wraparound here is asking for an oops on
> attempts to access the elements of buffer - kernel dereference of
> (char *)0xfffff000 on a 32bit box is already a bug.
> 
> It might be getting an invalid pointer, but arithmetical overflows
> are irrelevant.

The original bug report stated that search_buf = 0xfffff000 on entry,
and I'd quoted that at the start of my email:

On Apr 12, 2024, at 8:57 AM, Björn Töpel <bjorn@...nel.org> wrote:
> What I see in ext4_search_dir() is that search_buf is 0xfffff000, and at
> some point the address wraps to zero, and boom. I doubt that 0xfffff000
> is a sane address.

Now that you mention ERR_PTR() it definitely makes sense that this last
page HAS to be excluded.

So some other bug is passing the bad pointer to this code before this
error, or the arch is not correctly excluding this page from allocation.

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)