Received-SPF: pass (google.com: domain of linux-ext4+bounces-2083-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Andreas Dilger <adilger@dilger.ca>
Message-Id: <887E261B-3C76-4CD9-867B-5D087051D004@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_3417505C-A477-4CF5-8245-C5D2C05FBA72";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: riscv32 EXT4 splat, 6.8 regression?
Date: Sat, 13 Apr 2024 22:16:07 -0600
In-Reply-To: <20240414021555.GQ2118490@ZenIV>
Cc: Nam Cao <namcao@linutronix.de>,
 =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn@kernel.org>,
 linux-fsdevel <linux-fsdevel@vger.kernel.org>,
 Christian Brauner <brauner@kernel.org>,
 Jan Kara <jack@suse.cz>,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 linux-riscv@lists.infradead.org,
 Theodore Ts'o <tytso@mit.edu>,
 Ext4 Developers List <linux-ext4@vger.kernel.org>,
 Conor Dooley <conor@kernel.org>
To: Al Viro <viro@zeniv.linux.org.uk>
References: <878r1ibpdn.fsf@all.your.base.are.belong.to.us>
 <20240413164318.7260c5ef@namcao>
 <22E65CA5-A2C0-44A3-AB01-7514916A18FC@dilger.ca>
 <20240414021555.GQ2118490@ZenIV>


--Apple-Mail=_3417505C-A477-4CF5-8245-C5D2C05FBA72
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Apr 13, 2024, at 8:15 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>=20
> On Sat, Apr 13, 2024 at 07:46:03PM -0600, Andreas Dilger wrote:
>=20
>> 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.
>=20
> Not a chance.  *Any* page mapped there is a serious bug on any 32bit
> box.  Recall what ERR_PTR() is...
>=20
> 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.
>=20
> It might be getting an invalid pointer, but arithmetical overflows
> are irrelevant.

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

On Apr 12, 2024, at 8:57 AM, Bj=C3=B6rn T=C3=B6pel <bjorn@kernel.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


--Apple-Mail=_3417505C-A477-4CF5-8245-C5D2C05FBA72
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmYbWIcACgkQcqXauRfM
H+BZJg//dKG4ukz8K7Y4yBljOWxkY67dgXd7uaHxDtenGyHe/wDSByka2SfF7t2e
/JzZzOv8+cz+CzbgSu/Rtn9SetSmMlTTuOSf1CKvBGECQsDS5leR6fYJvuwou/Kq
14MuYBJUuqyBJ66XEKshi8J1Xr+ABf5dD53iKU+jlMaIRQDyk7dEgZRH9nKgOjLd
YwGGonfkTr2RrqGlvXzr+gSmMwF0RZZ3G+n/i4LAJ1hEGDlfJQczuHwV9lCKnw/S
pzRrd6v3KuA3DnRXa024dQxog1S1tyQSzM+xRtJm3YvU94q+BOt7prfjR7wSxE0U
6GzGSDnvRC5ou1c8BK/TJnzP6NMwCE5pQpXOKPpDmpvdfh7DF22dBCxqewWWCBoO
g4qxPp8Rs1pTCpAnsRteQTJL0QFgBck0H+y4pRIrt+INS8M52InzAHmQuuckXjDF
5pXQDQd8G4CRwDQIziB4H/IfaRNywB6LAZyzvtDAeOzMidUVFg6KQgmEVWxxgIa2
70yZXJH2WCLLi+d9a1sO3Kcyuyl7FVxOYKFgdKDLBzDaMYLU3iaADFN25MG3DLxF
83Y/WWYYQfRwAFAAVsqEVl67iCyGOiQUxiFgOQCDj/qz/l3S2RIPIdNSxQOdFem+
5r+gP1MuGAfM4dsnOhBF844Oh8e9Ot5Bd/ngImDLMcrohjsXB2s=
=rxuh
-----END PGP SIGNATURE-----

--Apple-Mail=_3417505C-A477-4CF5-8245-C5D2C05FBA72--