On Fri, Feb 20, 2026, at 18:27, Theo de Raadt wrote: >> Why are you trying to map memory outside the viable memory address space? > > And how do you know this value 'VM_MAXUSER_ADDRESS'? > > Or are you randomly choosing some other high address space value, and > only comparing it vaguely to VM_MAXUSER_ADDRESS? This varies greatly > architectures, and not just in number.
The way our mmap() hinting works is that we record the address of the last successful mmap() and then base the hint for the next mmap() on that previously-recorded address, adjusted appropriately upwards or downwards for required length and alignment. The idea is that a use-after-free bug should then ideally manifest as a SIGSEGV rather than reading random garbage from a subsequent, unrelated mmap(). (This scheme of course only helps if the OS cooperates by honoring the hint, but even if it doesn't, that's fine too; it just means a worse debugging experience, not incorrect program semantics.) As you can imagine, if you do the above in a loop for long enough, you'll eventually bump up against VM_MAXUSER_ADDRESS and get ENOMEM due to the hint sitting within that region. The point here is that we actually *don't* want to have to know about VM_MAXUSER_ADDRESS, nor have to retry mmap() without a hint when we get ENOMEM; we would rather the kernel just ignore the hint if addr >= VM_MAXUSER_ADDRESS, and place the mapping wherever it thinks is best. But also, my question about the randomness of mmap(NULL, ...) earlier still stands; if the resulting addresses are actually highly random, then the above scheme may just be a complete waste of time on OpenBSD anyway, because the OS would already be doing a better job of it than we could (which would be great!). I still think the kernel behavior here is odd and should be changed to be consistent one way or the other, but I guess it wouldn't affect us anymore.
