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