qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] linux-user/mmap.c: Avoid choosing NULL as st


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH v2] linux-user/mmap.c: Avoid choosing NULL as start address
Date: Sun, 7 Jan 2018 13:39:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

Le 07/01/2018 à 02:01, Maximilian Riemensberger a écrit :
> mmap() is required by the linux kernel ABI and POSIX to return a
> non-NULL address when the implementation chooses a start address for the
> mapping.
> 
> The current implementation of mmap_find_vma_reserved() can return NULL
> as start address of a mapping which leads to subsequent crashes inside
> the guests glibc, e.g. output of qemu-arm-static --strace executing a
> test binary stx_test:
> 
>     1879 
> mmap2(NULL,8388608,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0)
>  = 0x00000000
>     1879 write(2,0xf6fd39d0,79) stx_test: allocatestack.c:514: 
> allocate_stack: Assertion `mem != NULL' failed.
> 
> This patch fixes mmap_find_vma_reserved() by skipping NULL as start
> address while searching for a suitable mapping start address.
> 
> CC: Riku Voipio <address@hidden>
> CC: Laurent Vivier <address@hidden>
> CC: Peter Maydell <address@hidden>
> Signed-off-by: Maximilian Riemensberger <address@hidden>
> ---
> Changes since v1:
>     - Applied feedback from Laurent Vivier
> 
>  linux-user/mmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/linux-user/mmap.c b/linux-user/mmap.c
> index 4888f53..0fbfd6d 100644
> --- a/linux-user/mmap.c
> +++ b/linux-user/mmap.c
> @@ -234,7 +234,7 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start, 
> abi_ulong size)
>          if (prot) {
>              end_addr = addr;
>          }
> -        if (addr + size == end_addr) {
> +        if (addr && addr + size == end_addr) {
>              break;
>          }
>          addr -= qemu_host_page_size;
> 

Reviewed-by: Laurent Vivier <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]