qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Bug 1876373] [NEW] segfault mremap 4096
@ 2020-05-01 20:07 Jonathan Marler
  2020-05-01 20:29 ` [Bug 1876373] " Jonathan Marler
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Jonathan Marler @ 2020-05-01 20:07 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

a qemu-hosted process segfaults when the program calls mremap to shrink
the size of a buffer to 4096 that was allocated with mmap. See below for
a C program to reproduce this issue.  I was able to compile this program
for both i386 and 32-bit arm, and use qemu-i386 and qemu-arm to
reproduce the segfault.  If I run the i386 program natively on my x86_64
system, no segfault occurs.  Also note that if I change the mremap size
to something else such as 12288, no segfault occurs.  I also confirmed
using qemu's -singlestep debug option that the segfault occurs during
the mremap syscall.

If you save the source below to mremapbug.c, the following should
reproduce the issue given you have gcc-multilib:

gcc -m32 mremapbug.c
# works
./a.out
# segfault
qemu-i386 a.out

If you can also compile to arm, the same thing happens when running
"qemu-arm a.out".  I also tried compiling natively and running "qemu-
x86_64 a.out" but no segfault in that case, not sure if it's because it
is 64-bits or if it was because it was my native target.


#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>

int main(int argc, char *argv[])
{
  const size_t initial_size = 8192;

  printf("calling mmap, size=%llu\n", (unsigned long long)initial_size);
  void *mmap_ptr = mmap(NULL, initial_size,
                   PROT_READ | PROT_WRITE ,
                   MAP_PRIVATE | MAP_ANONYMOUS,
                   -1, 0);
  printf("mmap returned  : %p\n", mmap_ptr);
  if (mmap_ptr == MAP_FAILED) {
    perror("mmap");
    exit(1);
  }

  const size_t new_size = 4096;
  printf("calling mremap, size=%llu\n", (unsigned long long)new_size);
  void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0);
  printf("mremap returned: %p\n", remap_ptr);
  if (remap_ptr != mmap_ptr) {
    perror("mreamap");
    exit(1);
  }
  printf("Success: pointers match\n");
}


This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts.  I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1876373

Title:
  segfault mremap 4096

Status in QEMU:
  New

Bug description:
  a qemu-hosted process segfaults when the program calls mremap to
  shrink the size of a buffer to 4096 that was allocated with mmap. See
  below for a C program to reproduce this issue.  I was able to compile
  this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-
  arm to reproduce the segfault.  If I run the i386 program natively on
  my x86_64 system, no segfault occurs.  Also note that if I change the
  mremap size to something else such as 12288, no segfault occurs.  I
  also confirmed using qemu's -singlestep debug option that the segfault
  occurs during the mremap syscall.

  If you save the source below to mremapbug.c, the following should
  reproduce the issue given you have gcc-multilib:

  gcc -m32 mremapbug.c
  # works
  ./a.out
  # segfault
  qemu-i386 a.out

  If you can also compile to arm, the same thing happens when running
  "qemu-arm a.out".  I also tried compiling natively and running "qemu-
  x86_64 a.out" but no segfault in that case, not sure if it's because
  it is 64-bits or if it was because it was my native target.

  
  #define _GNU_SOURCE
  #include <stdlib.h>
  #include <stdio.h>
  #include <sys/mman.h>

  int main(int argc, char *argv[])
  {
    const size_t initial_size = 8192;

    printf("calling mmap, size=%llu\n", (unsigned long long)initial_size);
    void *mmap_ptr = mmap(NULL, initial_size,
                     PROT_READ | PROT_WRITE ,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);
    printf("mmap returned  : %p\n", mmap_ptr);
    if (mmap_ptr == MAP_FAILED) {
      perror("mmap");
      exit(1);
    }

    const size_t new_size = 4096;
    printf("calling mremap, size=%llu\n", (unsigned long long)new_size);
    void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0);
    printf("mremap returned: %p\n", remap_ptr);
    if (remap_ptr != mmap_ptr) {
      perror("mreamap");
      exit(1);
    }
    printf("Success: pointers match\n");
  }

  
  This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts.  I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1876373/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1876373] Re: segfault mremap 4096
  2020-05-01 20:07 [Bug 1876373] [NEW] segfault mremap 4096 Jonathan Marler
@ 2020-05-01 20:29 ` Jonathan Marler
  2020-05-02  4:38 ` Jonathan Marler
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Jonathan Marler @ 2020-05-01 20:29 UTC (permalink / raw)
  To: qemu-devel

Thanks to @LemonBoy for finding this:

It looks like this issue my be caused by this chunk of code in linux-
user/mmap.c

        if (prot == 0) {
            host_addr = mremap(g2h(old_addr), old_size, new_size, flags);
            if (host_addr != MAP_FAILED && reserved_va && old_size > new_size) {
                mmap_reserve(old_addr + old_size, new_size - old_size);
            }
        } else {
            errno = ENOMEM;
            host_addr = MAP_FAILED;
        }

if new_size is less than old_size (which is the case in my example
program) then we'll get an integer underflow which would cause a very
large value passed to mmap_reserve

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1876373

Title:
  segfault mremap 4096

Status in QEMU:
  New

Bug description:
  a qemu-hosted process segfaults when the program calls mremap to
  shrink the size of a buffer to 4096 that was allocated with mmap. See
  below for a C program to reproduce this issue.  I was able to compile
  this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-
  arm to reproduce the segfault.  If I run the i386 program natively on
  my x86_64 system, no segfault occurs.  Also note that if I change the
  mremap size to something else such as 12288, no segfault occurs.  I
  also confirmed using qemu's -singlestep debug option that the segfault
  occurs during the mremap syscall.

  If you save the source below to mremapbug.c, the following should
  reproduce the issue given you have gcc-multilib:

  gcc -m32 mremapbug.c
  # works
  ./a.out
  # segfault
  qemu-i386 a.out

  If you can also compile to arm, the same thing happens when running
  "qemu-arm a.out".  I also tried compiling natively and running "qemu-
  x86_64 a.out" but no segfault in that case, not sure if it's because
  it is 64-bits or if it was because it was my native target.

  
  #define _GNU_SOURCE
  #include <stdlib.h>
  #include <stdio.h>
  #include <sys/mman.h>

  int main(int argc, char *argv[])
  {
    const size_t initial_size = 8192;

    printf("calling mmap, size=%llu\n", (unsigned long long)initial_size);
    void *mmap_ptr = mmap(NULL, initial_size,
                     PROT_READ | PROT_WRITE ,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);
    printf("mmap returned  : %p\n", mmap_ptr);
    if (mmap_ptr == MAP_FAILED) {
      perror("mmap");
      exit(1);
    }

    const size_t new_size = 4096;
    printf("calling mremap, size=%llu\n", (unsigned long long)new_size);
    void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0);
    printf("mremap returned: %p\n", remap_ptr);
    if (remap_ptr != mmap_ptr) {
      perror("mreamap");
      exit(1);
    }
    printf("Success: pointers match\n");
  }

  
  This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts.  I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1876373/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1876373] Re: segfault mremap 4096
  2020-05-01 20:07 [Bug 1876373] [NEW] segfault mremap 4096 Jonathan Marler
  2020-05-01 20:29 ` [Bug 1876373] " Jonathan Marler
@ 2020-05-02  4:38 ` Jonathan Marler
  2020-05-02 23:45 ` Jonathan Marler
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Jonathan Marler @ 2020-05-02  4:38 UTC (permalink / raw)
  To: qemu-devel

I've submitted a patch, this is my first qemu patch so sorry if I didn't
format it correctly: https://lists.gnu.org/archive/html/qemu-
trivial/2020-05/msg00000.html

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1876373

Title:
  segfault mremap 4096

Status in QEMU:
  New

Bug description:
  a qemu-hosted process segfaults when the program calls mremap to
  shrink the size of a buffer to 4096 that was allocated with mmap. See
  below for a C program to reproduce this issue.  I was able to compile
  this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-
  arm to reproduce the segfault.  If I run the i386 program natively on
  my x86_64 system, no segfault occurs.  Also note that if I change the
  mremap size to something else such as 12288, no segfault occurs.  I
  also confirmed using qemu's -singlestep debug option that the segfault
  occurs during the mremap syscall.

  If you save the source below to mremapbug.c, the following should
  reproduce the issue given you have gcc-multilib:

  gcc -m32 mremapbug.c
  # works
  ./a.out
  # segfault
  qemu-i386 a.out

  If you can also compile to arm, the same thing happens when running
  "qemu-arm a.out".  I also tried compiling natively and running "qemu-
  x86_64 a.out" but no segfault in that case, not sure if it's because
  it is 64-bits or if it was because it was my native target.

  
  #define _GNU_SOURCE
  #include <stdlib.h>
  #include <stdio.h>
  #include <sys/mman.h>

  int main(int argc, char *argv[])
  {
    const size_t initial_size = 8192;

    printf("calling mmap, size=%llu\n", (unsigned long long)initial_size);
    void *mmap_ptr = mmap(NULL, initial_size,
                     PROT_READ | PROT_WRITE ,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);
    printf("mmap returned  : %p\n", mmap_ptr);
    if (mmap_ptr == MAP_FAILED) {
      perror("mmap");
      exit(1);
    }

    const size_t new_size = 4096;
    printf("calling mremap, size=%llu\n", (unsigned long long)new_size);
    void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0);
    printf("mremap returned: %p\n", remap_ptr);
    if (remap_ptr != mmap_ptr) {
      perror("mreamap");
      exit(1);
    }
    printf("Success: pointers match\n");
  }

  
  This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts.  I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1876373/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1876373] Re: segfault mremap 4096
  2020-05-01 20:07 [Bug 1876373] [NEW] segfault mremap 4096 Jonathan Marler
  2020-05-01 20:29 ` [Bug 1876373] " Jonathan Marler
  2020-05-02  4:38 ` Jonathan Marler
@ 2020-05-02 23:45 ` Jonathan Marler
  2020-08-20 15:04 ` Thomas Huth
  2020-08-20 15:15 ` Thomas Huth
  4 siblings, 0 replies; 6+ messages in thread
From: Jonathan Marler @ 2020-05-02 23:45 UTC (permalink / raw)
  To: qemu-devel

FYI, first patch in the previous comment was wrong.  This new patch is
the correct one: https://lists.gnu.org/archive/html/qemu-
devel/2020-05/msg00183.html

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1876373

Title:
  segfault mremap 4096

Status in QEMU:
  New

Bug description:
  a qemu-hosted process segfaults when the program calls mremap to
  shrink the size of a buffer to 4096 that was allocated with mmap. See
  below for a C program to reproduce this issue.  I was able to compile
  this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-
  arm to reproduce the segfault.  If I run the i386 program natively on
  my x86_64 system, no segfault occurs.  Also note that if I change the
  mremap size to something else such as 12288, no segfault occurs.  I
  also confirmed using qemu's -singlestep debug option that the segfault
  occurs during the mremap syscall.

  If you save the source below to mremapbug.c, the following should
  reproduce the issue given you have gcc-multilib:

  gcc -m32 mremapbug.c
  # works
  ./a.out
  # segfault
  qemu-i386 a.out

  If you can also compile to arm, the same thing happens when running
  "qemu-arm a.out".  I also tried compiling natively and running "qemu-
  x86_64 a.out" but no segfault in that case, not sure if it's because
  it is 64-bits or if it was because it was my native target.

  
  #define _GNU_SOURCE
  #include <stdlib.h>
  #include <stdio.h>
  #include <sys/mman.h>

  int main(int argc, char *argv[])
  {
    const size_t initial_size = 8192;

    printf("calling mmap, size=%llu\n", (unsigned long long)initial_size);
    void *mmap_ptr = mmap(NULL, initial_size,
                     PROT_READ | PROT_WRITE ,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);
    printf("mmap returned  : %p\n", mmap_ptr);
    if (mmap_ptr == MAP_FAILED) {
      perror("mmap");
      exit(1);
    }

    const size_t new_size = 4096;
    printf("calling mremap, size=%llu\n", (unsigned long long)new_size);
    void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0);
    printf("mremap returned: %p\n", remap_ptr);
    if (remap_ptr != mmap_ptr) {
      perror("mreamap");
      exit(1);
    }
    printf("Success: pointers match\n");
  }

  
  This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts.  I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1876373/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1876373] Re: segfault mremap 4096
  2020-05-01 20:07 [Bug 1876373] [NEW] segfault mremap 4096 Jonathan Marler
                   ` (2 preceding siblings ...)
  2020-05-02 23:45 ` Jonathan Marler
@ 2020-08-20 15:04 ` Thomas Huth
  2020-08-20 15:15 ` Thomas Huth
  4 siblings, 0 replies; 6+ messages in thread
From: Thomas Huth @ 2020-08-20 15:04 UTC (permalink / raw)
  To: qemu-devel

Fix has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=257a7e212d5e518ac5

** Changed in: qemu
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1876373

Title:
  segfault mremap 4096

Status in QEMU:
  Fix Released

Bug description:
  a qemu-hosted process segfaults when the program calls mremap to
  shrink the size of a buffer to 4096 that was allocated with mmap. See
  below for a C program to reproduce this issue.  I was able to compile
  this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-
  arm to reproduce the segfault.  If I run the i386 program natively on
  my x86_64 system, no segfault occurs.  Also note that if I change the
  mremap size to something else such as 12288, no segfault occurs.  I
  also confirmed using qemu's -singlestep debug option that the segfault
  occurs during the mremap syscall.

  If you save the source below to mremapbug.c, the following should
  reproduce the issue given you have gcc-multilib:

  gcc -m32 mremapbug.c
  # works
  ./a.out
  # segfault
  qemu-i386 a.out

  If you can also compile to arm, the same thing happens when running
  "qemu-arm a.out".  I also tried compiling natively and running "qemu-
  x86_64 a.out" but no segfault in that case, not sure if it's because
  it is 64-bits or if it was because it was my native target.

  
  #define _GNU_SOURCE
  #include <stdlib.h>
  #include <stdio.h>
  #include <sys/mman.h>

  int main(int argc, char *argv[])
  {
    const size_t initial_size = 8192;

    printf("calling mmap, size=%llu\n", (unsigned long long)initial_size);
    void *mmap_ptr = mmap(NULL, initial_size,
                     PROT_READ | PROT_WRITE ,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);
    printf("mmap returned  : %p\n", mmap_ptr);
    if (mmap_ptr == MAP_FAILED) {
      perror("mmap");
      exit(1);
    }

    const size_t new_size = 4096;
    printf("calling mremap, size=%llu\n", (unsigned long long)new_size);
    void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0);
    printf("mremap returned: %p\n", remap_ptr);
    if (remap_ptr != mmap_ptr) {
      perror("mreamap");
      exit(1);
    }
    printf("Success: pointers match\n");
  }

  
  This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts.  I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1876373/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1876373] Re: segfault mremap 4096
  2020-05-01 20:07 [Bug 1876373] [NEW] segfault mremap 4096 Jonathan Marler
                   ` (3 preceding siblings ...)
  2020-08-20 15:04 ` Thomas Huth
@ 2020-08-20 15:15 ` Thomas Huth
  4 siblings, 0 replies; 6+ messages in thread
From: Thomas Huth @ 2020-08-20 15:15 UTC (permalink / raw)
  To: qemu-devel

Patch has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=257a7e212d5e518ac53b

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1876373

Title:
  segfault mremap 4096

Status in QEMU:
  Fix Released

Bug description:
  a qemu-hosted process segfaults when the program calls mremap to
  shrink the size of a buffer to 4096 that was allocated with mmap. See
  below for a C program to reproduce this issue.  I was able to compile
  this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-
  arm to reproduce the segfault.  If I run the i386 program natively on
  my x86_64 system, no segfault occurs.  Also note that if I change the
  mremap size to something else such as 12288, no segfault occurs.  I
  also confirmed using qemu's -singlestep debug option that the segfault
  occurs during the mremap syscall.

  If you save the source below to mremapbug.c, the following should
  reproduce the issue given you have gcc-multilib:

  gcc -m32 mremapbug.c
  # works
  ./a.out
  # segfault
  qemu-i386 a.out

  If you can also compile to arm, the same thing happens when running
  "qemu-arm a.out".  I also tried compiling natively and running "qemu-
  x86_64 a.out" but no segfault in that case, not sure if it's because
  it is 64-bits or if it was because it was my native target.

  
  #define _GNU_SOURCE
  #include <stdlib.h>
  #include <stdio.h>
  #include <sys/mman.h>

  int main(int argc, char *argv[])
  {
    const size_t initial_size = 8192;

    printf("calling mmap, size=%llu\n", (unsigned long long)initial_size);
    void *mmap_ptr = mmap(NULL, initial_size,
                     PROT_READ | PROT_WRITE ,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);
    printf("mmap returned  : %p\n", mmap_ptr);
    if (mmap_ptr == MAP_FAILED) {
      perror("mmap");
      exit(1);
    }

    const size_t new_size = 4096;
    printf("calling mremap, size=%llu\n", (unsigned long long)new_size);
    void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0);
    printf("mremap returned: %p\n", remap_ptr);
    if (remap_ptr != mmap_ptr) {
      perror("mreamap");
      exit(1);
    }
    printf("Success: pointers match\n");
  }

  
  This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts.  I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1876373/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-08-20 15:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-01 20:07 [Bug 1876373] [NEW] segfault mremap 4096 Jonathan Marler
2020-05-01 20:29 ` [Bug 1876373] " Jonathan Marler
2020-05-02  4:38 ` Jonathan Marler
2020-05-02 23:45 ` Jonathan Marler
2020-08-20 15:04 ` Thomas Huth
2020-08-20 15:15 ` Thomas Huth

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).