On Fri, Jul 25, 2025 at 09:10:25PM +0200, Jann Horn wrote:
On Fri, Jul 25, 2025 at 7:28 PM Lorenzo Stoakes lorenzo.stoakes@oracle.com wrote:
On Fri, Jul 25, 2025 at 07:11:49PM +0200, Jann Horn wrote:
On Fri, Jul 11, 2025 at 1:38 PM Lorenzo Stoakes lorenzo.stoakes@oracle.com wrote:
Note that any failures encountered will result in a partial move. Since an mremap() can fail at any time, this might result in only some of the VMAs being moved.
Note that failures are very rare and typically require an out of a memory condition or a mapping limit condition to be hit, assuming the VMAs being moved are valid.
Hrm. So if userspace tries to move a series of VMAs with mremap(), and the operation fails, and userspace assumes the old syscall semantics, userspace could assume that its memory is still at the old address, when that's actually not true; and if userspace tries to access it there, userspace UAF happens?
At 6pm on the last day of the cycle? :) dude :) this long week gets ever longer...
To be clear, I very much do not expect you to instantly reply to random patch review mail I send you late on a Friday evening. :P
Haha sure, just keen to clarify things on this!
Otherwise for mapping limit we likely hit it right away. I moved all the checks up front for standard VMA/param errors.
Ah, I missed that part.
Yeah the refactoring part of the series prior to this patch goes to great lengths to prepare for this (including in moving tests earlier - all of which I confirmed were good to be done earlier).
:)