linux-user/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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 <riku.voipio@iki.fi>
CC: Laurent Vivier <laurent@vivier.eu>
CC: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Maximilian Riemensberger <riemensberger@cadami.net>
---
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..20cc5a7 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -221,7 +221,7 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start, abi_ulong size)
addr = end_addr - qemu_host_page_size;
while (1) {
- if (addr > end_addr) {
+ if (!addr || addr > end_addr) {
if (looped) {
return (abi_ulong)-1;
}
--
2.7.4
On 06.01.18 18:00, Maximilian Riemensberger wrote:
> 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.
I should have added:
Fixes: 59e9d91c7ae1b655997aec61c08eec1685414117 ("linux-user: resolve reserved_va vma downwards")
Cheers,
Max
>
> CC: Riku Voipio <riku.voipio@iki.fi>
> CC: Laurent Vivier <laurent@vivier.eu>
> CC: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Maximilian Riemensberger <riemensberger@cadami.net>
> ---
> 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..20cc5a7 100644
> --- a/linux-user/mmap.c
> +++ b/linux-user/mmap.c
> @@ -221,7 +221,7 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start, abi_ulong size)
> addr = end_addr - qemu_host_page_size;
>
> while (1) {
> - if (addr > end_addr) {
> + if (!addr || addr > end_addr) {
> if (looped) {
> return (abi_ulong)-1;
> }
>
--
----------------------------------------------------------------------
Cadami UG (haftungsbeschränkt)
Waagstraße 10, 85386 Eching (near Munich), Germany
Office: c/o Wayra, Kaufingerstraße 15, 80331 Munich, Germany
Contact: +49-176-63360306, riemensberger@cadami.net, www.cadami.net
Geschäftsführer: Andreas Dotzler, Michael Heindlmaier,
Thomas Kühn, Maximilian Riemensberger
Sitz der Gesellschaft: Eching, HRB 219979 Amtsgericht München
USt-IdNr.: DE301293803
----------------------------------------------------------------------
Le 06/01/2018 à 18:00, 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 <riku.voipio@iki.fi>
> CC: Laurent Vivier <laurent@vivier.eu>
> CC: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Maximilian Riemensberger <riemensberger@cadami.net>
> ---
> 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..20cc5a7 100644
> --- a/linux-user/mmap.c
> +++ b/linux-user/mmap.c
> @@ -221,7 +221,7 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start, abi_ulong size)
> addr = end_addr - qemu_host_page_size;
>
> while (1) {
> - if (addr > end_addr) {
> + if (!addr || addr > end_addr) {
> if (looped) {
> return (abi_ulong)-1;
> }
I think this is correct, but it would be clearer to not exit the loop if
addr is NULL, something like:
@@ -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;
The result is the same because with the "addr -= qemu_host_page_size"
addr becomes greater than end_addr on the next loop.
Thanks,
Laurent
On 06.01.18 21:51, Laurent Vivier wrote:
> Le 06/01/2018 à 18:00, 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 <riku.voipio@iki.fi>
>> CC: Laurent Vivier <laurent@vivier.eu>
>> CC: Peter Maydell <peter.maydell@linaro.org>
>> Signed-off-by: Maximilian Riemensberger <riemensberger@cadami.net>
>> ---
>> 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..20cc5a7 100644
>> --- a/linux-user/mmap.c
>> +++ b/linux-user/mmap.c
>> @@ -221,7 +221,7 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start, abi_ulong size)
>> addr = end_addr - qemu_host_page_size;
>>
>> while (1) {
>> - if (addr > end_addr) {
>> + if (!addr || addr > end_addr) {
>> if (looped) {
>> return (abi_ulong)-1;
>> }
>
> I think this is correct, but it would be clearer to not exit the loop if
> addr is NULL, something like:
>
> @@ -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;
>
> The result is the same because with the "addr -= qemu_host_page_size"
> addr becomes greater than end_addr on the next loop.
Sure. This patch also fixes the problem for me. Should I respin
or do you send this patch directly?
Thanks.
Max
>
> Thanks,
> Laurent
>
--
----------------------------------------------------------------------
Cadami UG (haftungsbeschränkt)
Waagstraße 10, 85386 Eching (near Munich), Germany
Office: c/o Wayra, Kaufingerstraße 15, 80331 Munich, Germany
Contact: +49-176-63360306, riemensberger@cadami.net, www.cadami.net
Geschäftsführer: Andreas Dotzler, Michael Heindlmaier,
Thomas Kühn, Maximilian Riemensberger
Sitz der Gesellschaft: Eching, HRB 219979 Amtsgericht München
USt-IdNr.: DE301293803
----------------------------------------------------------------------
© 2016 - 2025 Red Hat, Inc.