From: Matthew Lugg <mlugg@mlugg.co.uk>
To: qemu-devel@nongnu.org
Cc: laurent@vivier.eu, qemu-stable@nongnu.org,
Matthew Lugg <mlugg@mlugg.co.uk>
Subject: [PATCH 0/4] linux-user: fix several mremap bugs
Date: Sat, 11 Oct 2025 21:03:33 +0100 [thread overview]
Message-ID: <20251011200337.30258-1-mlugg@mlugg.co.uk> (raw)
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
next reply other threads:[~2025-10-11 20:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 20:03 Matthew Lugg [this message]
2025-10-11 20:03 ` [PATCH 1/4] linux-user: fix mremap unmapping adjacent region Matthew Lugg
2025-10-11 20:03 ` [PATCH 2/4] linux-user: fix mremap errors for invalid ranges Matthew Lugg
2025-10-11 20:03 ` [PATCH 3/4] linux-user: fix reserved_va page leak in do_munmap Matthew Lugg
2025-10-11 20:03 ` [PATCH 4/4] tests: add tcg coverage for fixed mremap bugs Matthew Lugg
2025-10-11 20:15 ` Matthew Lugg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251011200337.30258-1-mlugg@mlugg.co.uk \
--to=mlugg@mlugg.co.uk \
--cc=laurent@vivier.eu \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).