On Apr 13, 2024, at 8:15 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
