This version of the series should address all feedback I received. The original
cover letter is replicated below.

I was recently debugging a strange crash in a downstream project which turned
out to be a QEMU bug related to the `mremap` implementation in linux-user. In
practice, this bug essentially led to arbitrary memory regions being unmapped
when a 32-bit guest, running on a 64-bit host, uses `mremap` to shrink a memory
mapping.

The first patch in this set resolves that bug. Since the patch is very simple,
and the bug is quite likely to be hit, I suspect that that commit is a good
candidate for qemu-stable.

The following two patches just resolve two more bugs I became aware of whilst
working on this code. I believe the messages in those patches contain all
necessary context. They are less critical and the fixes more complex, so are
likely not suitable for backporting into qemu-stable.

The final commits adds tcg tests for the fixed `mremap` behavior. The third fix
is unfortunately difficult to test programmatically, but I have confirmed that
it behaves as expected by observing the output of `strace qemu-i386 repro`,
where `repro` is the following C program:

    #define _GNU_SOURCE
    #include <stddef.h>
    #include <sys/mman.h>
    int main(void) {
        char *a = mmap(NULL, 4097, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
        char *b = mmap(NULL, 4097, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
        mremap(b, 4097, 4097, MREMAP_FIXED | MREMAP_MAYMOVE, a);
        // QEMU has now leaked a page of its memory reservation!
        return 0;
    }

Prior to the patch, as the comment says, QEMU leaks a page of its address space
reservation (i.e. the page becomes unmapped). After the patch, QEMU correctly
reclaims that page with `mmap`.

Matthew Lugg (4):
  linux-user: fix mremap unmapping adjacent region
  linux-user: fix mremap errors for invalid ranges
  linux-user: fix reserved_va page leak in do_munmap
  tests: add tcg coverage for fixed mremap bugs

 linux-user/mmap.c               | 16 ++++++++-----
 tests/tcg/multiarch/test-mmap.c | 42 +++++++++++++++++++++++++++++++--
 2 files changed, 50 insertions(+), 8 deletions(-)

-- 
2.51.2

On 11/17/25 17:09, Matthew Lugg wrote:
> This version of the series should address all feedback I received. The original
> cover letter is replicated below.
> 
> I was recently debugging a strange crash in a downstream project which turned
> out to be a QEMU bug related to the `mremap` implementation in linux-user. In
> practice, this bug essentially led to arbitrary memory regions being unmapped
> when a 32-bit guest, running on a 64-bit host, uses `mremap` to shrink a memory
> mapping.
> 
> The first patch in this set resolves that bug. Since the patch is very simple,
> and the bug is quite likely to be hit, I suspect that that commit is a good
> candidate for qemu-stable.
> 
> The following two patches just resolve two more bugs I became aware of whilst
> working on this code. I believe the messages in those patches contain all
> necessary context. They are less critical and the fixes more complex, so are
> likely not suitable for backporting into qemu-stable.
> 
> The final commits adds tcg tests for the fixed `mremap` behavior. The third fix
> is unfortunately difficult to test programmatically, but I have confirmed that
> it behaves as expected by observing the output of `strace qemu-i386 repro`,
> where `repro` is the following C program:
> 
>      #define _GNU_SOURCE
>      #include <stddef.h>
>      #include <sys/mman.h>
>      int main(void) {
>          char *a = mmap(NULL, 4097, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>          char *b = mmap(NULL, 4097, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>          mremap(b, 4097, 4097, MREMAP_FIXED | MREMAP_MAYMOVE, a);
>          // QEMU has now leaked a page of its memory reservation!
>          return 0;
>      }
> 
> Prior to the patch, as the comment says, QEMU leaks a page of its address space
> reservation (i.e. the page becomes unmapped). After the patch, QEMU correctly
> reclaims that page with `mmap`.
> 
> Matthew Lugg (4):
>    linux-user: fix mremap unmapping adjacent region
>    linux-user: fix mremap errors for invalid ranges
>    linux-user: fix reserved_va page leak in do_munmap
>    tests: add tcg coverage for fixed mremap bugs
> 
>   linux-user/mmap.c               | 16 ++++++++-----
>   tests/tcg/multiarch/test-mmap.c | 42 +++++++++++++++++++++++++++++++--
>   2 files changed, 50 insertions(+), 8 deletions(-)
> 

Hey everyone, just bumping this series since I suspect it got lost. It 
should be fairly straightforward to get this in: patches 1 and 3 were 
already approved here, and 2 and 4 only have small changes since v1 to 
account for feedback.

Let me know if anything else is needed on my end---and happy new year!

-- 
Matthew

On 1/6/26 23:04, Matthew Lugg wrote:
> On 11/17/25 17:09, Matthew Lugg wrote:
>> This version of the series should address all feedback I received. The original
>> cover letter is replicated below.
>>
>> I was recently debugging a strange crash in a downstream project which turned
>> out to be a QEMU bug related to the `mremap` implementation in linux-user. In
>> practice, this bug essentially led to arbitrary memory regions being unmapped
>> when a 32-bit guest, running on a 64-bit host, uses `mremap` to shrink a memory
>> mapping.
>>
>> The first patch in this set resolves that bug. Since the patch is very simple,
>> and the bug is quite likely to be hit, I suspect that that commit is a good
>> candidate for qemu-stable.
>>
>> The following two patches just resolve two more bugs I became aware of whilst
>> working on this code. I believe the messages in those patches contain all
>> necessary context. They are less critical and the fixes more complex, so are
>> likely not suitable for backporting into qemu-stable.
>>
>> The final commits adds tcg tests for the fixed `mremap` behavior. The third fix
>> is unfortunately difficult to test programmatically, but I have confirmed that
>> it behaves as expected by observing the output of `strace qemu-i386 repro`,
>> where `repro` is the following C program:
>>
>>      #define _GNU_SOURCE
>>      #include <stddef.h>
>>      #include <sys/mman.h>
>>      int main(void) {
>>          char *a = mmap(NULL, 4097, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 
>> -1, 0);
>>          char *b = mmap(NULL, 4097, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 
>> -1, 0);
>>          mremap(b, 4097, 4097, MREMAP_FIXED | MREMAP_MAYMOVE, a);
>>          // QEMU has now leaked a page of its memory reservation!
>>          return 0;
>>      }
>>
>> Prior to the patch, as the comment says, QEMU leaks a page of its address space
>> reservation (i.e. the page becomes unmapped). After the patch, QEMU correctly
>> reclaims that page with `mmap`.
>>
>> Matthew Lugg (4):
>>    linux-user: fix mremap unmapping adjacent region
>>    linux-user: fix mremap errors for invalid ranges
>>    linux-user: fix reserved_va page leak in do_munmap
>>    tests: add tcg coverage for fixed mremap bugs
>>
>>   linux-user/mmap.c               | 16 ++++++++-----
>>   tests/tcg/multiarch/test-mmap.c | 42 +++++++++++++++++++++++++++++++--
>>   2 files changed, 50 insertions(+), 8 deletions(-)
>>
> 
> Hey everyone, just bumping this series since I suspect it got lost. It should be fairly 
> straightforward to get this in: patches 1 and 3 were already approved here, and 2 and 4 
> only have small changes since v1 to account for feedback.
> 
> Let me know if anything else is needed on my end---and happy new year!
> 

Queued, thanks.

r~