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

Bug#889817: marked as done (linux: kernel does not always provide a heap [alpha arm64 mips64el ppc64el ppc64 s390x sparc64])

Your message dated Mon, 24 May 2021 08:31:14 +0200
with message-id <YKtIMjZwgtZqq8Jg@eldamar.lan>
and subject line Re: Bug#889817: linux: kernel does not always provide a heap [alpha arm64 mips64el ppc64el ppc64 s390x sparc64]
has caused the Debian Bug report #889817,
regarding linux: kernel does not always provide a heap [alpha arm64 mips64el ppc64el ppc64 s390x sparc64]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
889817: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889817
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Source: linux
Version: 4.14.13-1
Severity: normal
Tags: upstream

When ASLR is enabled (which is the default), the Linux kernel on at
least alpha, arm64, mips64el, ppc64el, ppc64, s390x and sparc64 might
not provide a heap to the program. This is the case for example when
the program is run through the program interpreter ld.so. This happens
with different probability depending on the architecture. This causes
issues with GLIBC tunables support, which needs to be able to reserve
a few hundred bytes of memory through brk. This is reproducible with
at least kernel 4.9 and 4.15, and it's likely that the issue has always
been there.

The following script, based on one from James Cowgill, shows the issue:

#!/bin/bash
export LC_ALL=C

interp=$(readelf --headers /bin/cat | grep 'Requesting program interpreter' | sed -e 's/.*: //' -e 's/]//')

for i in {1..10000}
do
        OUT=$($interp /bin/cat /proc/self/maps)
        if [[ $OUT != *heap* ]]
        then
                echo -n F
                echo "$OUT"
        else
                echo -n .
        fi
done

A workaround is to set /proc/sys/kernel/randomize_va_space to 1.

--- End Message ---
--- Begin Message --- 
Source: linux
Source-Version: 5.10.38-1

Hi,

On Wed, Feb 07, 2018 at 12:37:44PM +0100, Aurelien Jarno wrote:
> Source: linux
> Version: 4.14.13-1
> Severity: normal
> Tags: upstream
> 
> When ASLR is enabled (which is the default), the Linux kernel on at
> least alpha, arm64, mips64el, ppc64el, ppc64, s390x and sparc64 might
> not provide a heap to the program. This is the case for example when
> the program is run through the program interpreter ld.so. This happens
> with different probability depending on the architecture. This causes
> issues with GLIBC tunables support, which needs to be able to reserve
> a few hundred bytes of memory through brk. This is reproducible with
> at least kernel 4.9 and 4.15, and it's likely that the issue has always
> been there.
> 
> The following script, based on one from James Cowgill, shows the issue:
> 
> #!/bin/bash
> export LC_ALL=C
> 
> interp=$(readelf --headers /bin/cat | grep 'Requesting program interpreter' | sed -e 's/.*: //' -e 's/]//')
> 
> for i in {1..10000}
> do
>         OUT=$($interp /bin/cat /proc/self/maps)
>         if [[ $OUT != *heap* ]]
>         then
>                 echo -n F
>                 echo "$OUT"
>         else
>                 echo -n .
>         fi
> done
> 
> A workaround is to set /proc/sys/kernel/randomize_va_space to 1.

As discussed on IRC, I was not able to trigger this behaviour with
4.19.181-1 on amdahl (arm64), zelenka (s390x) or plummer (ppc64el). So
guess the issue has been fixed in meanwhile somewhere.

Not sure it is worth trying to bisect and finding the fixing
commit(s).

But for now closing with all recent versions in supported branches.

Regards,
Salvatore

--- End Message ---
Reply to: