I tried out the MAP_FIXED_NOREPLACE API introduced in Linux 4.17 for a minor use case in my hardened allocator and it turns out that it has been very broken since it was introduced. It can clobber adjacent mappings:
marc.info/?l=linux-mm&m=
It will hopefully be fixed in 4.19.
Conversation
It's a serious memory corruption bug mitigated by the fact that barely anything has adopted this API. Some users of the API like the kernel itself were completely broken / incorrect before it existed, so moving to it wasn't a regression for those but wasn't a complete fix either.
1
I think the thought process for introducing this API was wrong which led to it being broken. The correct way to use MAP_FIXED and MREMAP_FIXED is replacing an existing mapping known to exist. MAP_FIXED_NOREPLACE is only an *optimization* for using mmap hints *without* MAP_FIXED.
Replying to
It's an optimization avoiding the need to unmap the mapping created at the wrong address by a failed attempt at using a hint. It can be introduced to existing code using the pattern just by adding MAP_FIXED_NOREPLACE as a flag and it will just keep working as is on older kernels.
1
2
Replying to
Which always existed just by omitting MAP_FIXED, except on broken grsec nonsense that refused to honor the requested address when available.
2
Replying to
Yeah, I don't see any other way to view MAP_FIXED_NOREPLACE as an optimization avoiding the need to munmap failed attempts to map at the hint address. It has the potential to be useful for my hardened allocator but it ended up causing memory corruption since it's very broken...
1