Hi Aurelien,
On Wed, May 26, 2021 at 06:09:45PM +0200, Aurelien Jarno wrote:
> control: fixed 889817 5.2.6-1
> control: fixed 889817 4.19.87-1
>
> Hi Salvatore,
>
> On 2021-05-24 08:31, Salvatore Bonaccorso wrote:
> > 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).
>
> I have found that the problem has been fixed in that upstream commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bbdc6076d2e5d07db44e74c11b01a3e27ab90b32
>
> This commit went into kernel 5.2, and was later backported in kernel
> 4.19.75.
>
> > But for now closing with all recent versions in supported branches.
>
> This mail should update the version in the BTS to the corresponding
> Debian version.
Very nice, thanks a lot for digging deeper into it to find the fixing
commit!
Regards,
Salvatore
