linux-user/mmap.c | 75 +++++++++++++-------------------- tests/tcg/multiarch/test-mmap.c | 47 ++++++++++++++++++--- 2 files changed, 71 insertions(+), 51 deletions(-)
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 | 75 +++++++++++++--------------------
tests/tcg/multiarch/test-mmap.c | 47 ++++++++++++++++++---
2 files changed, 71 insertions(+), 51 deletions(-)
--
2.51.0
A friendly ping? Has this series been forgotten?
It looks like it should be picked up for 10.2 release.
Thanks,
/mjt
On 10/11/25 23:03, Matthew Lugg wrote:
> 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 | 75 +++++++++++++--------------------
> tests/tcg/multiarch/test-mmap.c | 47 ++++++++++++++++++---
> 2 files changed, 71 insertions(+), 51 deletions(-)
>
On Mon, 17 Nov 2025 at 08:40, Michael Tokarev <mjt@tls.msk.ru> wrote: > > A friendly ping? Has this series been forgotten? > It looks like it should be picked up for 10.2 release. No, there are review comments on the series that need to be addressed before it can be applied. thanks -- PMM
On 11/17/25 14:42, Peter Maydell wrote: > On Mon, 17 Nov 2025 at 08:40, Michael Tokarev <mjt@tls.msk.ru> wrote: >> >> A friendly ping? Has this series been forgotten? >> It looks like it should be picked up for 10.2 release. > > No, there are review comments on the series that need to be > addressed before it can be applied. Yes that's what I actually mean, - just used the wrong wording. What I mean is that this series is better be fixed and applied before/for 10.2. Thanks, /mjt
(Sorry for top post, replying on mobile.) Ah, yes, I'd kind of forgotten about this; apologies! I'll aim to address the feedback and send a new version of the series by the end of today (UTC+0). Thanks for the ping! On 17 November 2025 11:43:49 GMT, Michael Tokarev <mjt@tls.msk.ru> wrote: >On 11/17/25 14:42, Peter Maydell wrote: >> On Mon, 17 Nov 2025 at 08:40, Michael Tokarev <mjt@tls.msk.ru> wrote: >>> >>> A friendly ping? Has this series been forgotten? >>> It looks like it should be picked up for 10.2 release. >> >> No, there are review comments on the series that need to be >> addressed before it can be applied. > >Yes that's what I actually mean, - just used the wrong wording. >What I mean is that this series is better be fixed and applied >before/for 10.2. > >Thanks, > >/mjt
On Mon, 17 Nov 2025 at 11:43, Michael Tokarev <mjt@tls.msk.ru> wrote: > > On 11/17/25 14:42, Peter Maydell wrote: > > On Mon, 17 Nov 2025 at 08:40, Michael Tokarev <mjt@tls.msk.ru> wrote: > >> > >> A friendly ping? Has this series been forgotten? > >> It looks like it should be picked up for 10.2 release. > > > > No, there are review comments on the series that need to be > > addressed before it can be applied. > > Yes that's what I actually mean, - just used the wrong wording. > What I mean is that this series is better be fixed and applied > before/for 10.2. It would be nice, but AFAIK they're not regressions. Patch 1 is reviewed and could be applied, I guess. thanks -- PMM
On 11/17/25 14:46, Peter Maydell wrote: > On Mon, 17 Nov 2025 at 11:43, Michael Tokarev <mjt@tls.msk.ru> wrote: .. >> Yes that's what I actually mean, - just used the wrong wording. >> What I mean is that this series is better be fixed and applied >> before/for 10.2. > > It would be nice, but AFAIK they're not regressions. They're still bugfixes. > Patch 1 is reviewed and could be applied, I guess. I can push it through the trivial-patches tree - it is actually trival. Queued up now. Thanks, /mjt
© 2016 - 2026 Red Hat, Inc.