Debian Bug report logs - #522849
Bash xrealloc randomly fails

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: James Y Knight <foom@fuhm.net>

To: submit@bugs.debian.org

Subject: Bash xrealloc randomly fails

Date: Mon, 6 Apr 2009 18:25:05 -0400

Package: bash
Version: 3.2-4

I'm on an x86_64 machine.

I believe this bug is due to Bash's builtin malloc implementation only  
supporting sbrk() and not mmap() to get memory.

I'd like to suggest that the correct resolution of this bug is to  
disable bash's builtin malloc and simply use glibc's. I'm not sure  
whether or not this should be considered a kernel bug as well.

More details:

bash fails with a message like:
xrealloc: ../bash/general.c:888: cannot reallocate 262144 bytes (0  
bytes allocated)
(not always that exact line in the source, but that particular failure  
line is pretty common, I expect because it's allocating a lot of  
memory).

This started happening after an upgrade from kernel 2.6.22 to kernel  
2.6.26 (non-debian kernels). I've tracked it down to this new feature:
<<<
1.9. BRK and PIE executable randomization

Exec-shield is a Red Hat that was started in 2003 by Red Hat to
implement several security protections and is mainly used in Red Hat and
Fedora. Many features have already been merged lot of time ago, but not
all of them. In 2.6.25 two of them are being merged: brk() randomization
and PIE executable randomization. Those two features should make the
address space randomization on i386 and x86_64 complete.

http://kernelnewbies.org/Linux_2_6_25#head-fc71477174376b69ac7c3cd153ed513d25bf2cae
<<<

The randomized brk placement is disableable via "echo 1 > /proc/sys/ 
kernel/randomize_va_space". When that value is set to 1, the failures  
stop happening. When it's set to 2 (default value for my kernel), bash  
randomly fails with the above error.

It seems that what is happening is that the randomized heap placement  
is sometimes causing there to be shared libraries mapped close enough  
after the heap such that there's not enough room for expansion. And  
since bash's malloc can only use sbrk memory, it simply fails at that  
point.

I'll also note that the placement of libraries in low memory around  
the heap only happens if you've set a stack size ulimit, e.g. "ulimit - 
S -s 10240".

Here's /proc/<pid>/maps of a process shortly before it fails:

00110000-0012b000 r-xp 00000000 08:04  
41272590                           /lib/ld-2.7.so
0032a000-0032c000 rw-p 0001a000 08:04  
41272590                           /lib/ld-2.7.so
00400000-004ba000 r-xp 00000000 08:04  
41271303                           /bin/bash
006b9000-006c3000 rw-p 000b9000 08:04  
41271303                           /bin/bash
006c3000-006c8000 rw-p 006c3000 00:00 0
006c8000-00702000 r-xp 00000000 08:04  
41272640                           /lib/libncurses.so.5.6
00702000-00902000 ---p 0003a000 08:04  
41272640                           /lib/libncurses.so.5.6
00902000-00907000 rw-p 0003a000 08:04  
41272640                           /lib/libncurses.so.5.6
00907000-00909000 r-xp 00000000 08:04  
41272625                           /lib/libdl-2.7.so
00909000-00b09000 ---p 00002000 08:04  
41272625                           /lib/libdl-2.7.so
00b09000-00b0b000 rw-p 00002000 08:04  
41272625                           /lib/libdl-2.7.so
00b0b000-00c49000 r-xp 00000000 08:04  
41272608                           /lib/libc-2.7.so
00c49000-00e49000 ---p 0013e000 08:04  
41272608                           /lib/libc-2.7.so
00e49000-00e4c000 r--p 0013e000 08:04  
41272608                           /lib/libc-2.7.so
00e4c000-00e4e000 rw-p 00141000 08:04  
41272608                           /lib/libc-2.7.so
00e4e000-00e53000 rw-p 00e4e000 00:00 0
00e53000-00e5a000 r-xp 00000000 08:04  
41272645                           /lib/libnss_compat-2.7.so
00e5a000-01059000 ---p 00007000 08:04  
41272645                           /lib/libnss_compat-2.7.so
01059000-0105b000 rw-p 00006000 08:04  
41272645                           /lib/libnss_compat-2.7.so
0105b000-01064000 r-xp 00000000 08:04  
41272653                           /lib/libnss_nis-2.7.so
01064000-01264000 ---p 00009000 08:04  
41272653                           /lib/libnss_nis-2.7.so
01264000-01266000 rw-p 00009000 08:04  
41272653                           /lib/libnss_nis-2.7.so
01266000-01270000 r-xp 00000000 08:04  
41272649                           /lib/libnss_files-2.7.so
01270000-0146f000 ---p 0000a000 08:04  
41272649                           /lib/libnss_files-2.7.so
0146f000-01471000 rw-p 00009000 08:04  
41272649                           /lib/libnss_files-2.7.so
01471000-01473000 r-xp 00000000 08:04  
41320632                           /usr/lib/gconv/ISO8859-1.so
01473000-01672000 ---p 00002000 08:04  
41320632                           /usr/lib/gconv/ISO8859-1.so
01672000-01674000 rw-p 00001000 08:04  
41320632                           /usr/lib/gconv/ISO8859-1.so
01e9d000-01ead000 rw-p 01e9d000 00:00  
0                                  [heap]
01f24000-01f38000 r-xp 00000000 08:04  
41272643                           /lib/libnsl-2.7.so
01f38000-02137000 ---p 00014000 08:04  
41272643                           /lib/libnsl-2.7.so
02137000-02139000 rw-p 00013000 08:04  
41272643                           /lib/libnsl-2.7.so
02139000-0213b000 rw-p 02139000 00:00 0
7f88235f9000-7f8823600000 r--s 00000000 08:04  
41320688                   /usr/lib/gconv/gconv-modules.cache
7f8823600000-7f8823775000 r--p 00000000 08:04  
41353218                   /usr/lib/locale/locale-archive
7f8823775000-7f8823777000 rw-p 7f8823775000 00:00 0
7f882377d000-7f8823780000 rw-p 7f882377d000 00:00 0
7fff2b76b000-7fff2b780000 rw-p 7ffffffea000 00:00  
0                      [stack]
7fff2b7ff000-7fff2b800000 r-xp 7fff2b7ff000 00:00  
0                      [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00  
0                  [vsyscall]

Message #10 received at 522849@bugs.debian.org (full text, mbox, reply):

From: James Y Knight <foom@fuhm.net>

To: 522849@bugs.debian.org

Subject: Execshield kernel patch partially to blame

Date: Tue, 7 Apr 2009 11:07:29 -0400

So I attempted to reproduce my issue with a debian 2.6.26 kernel, and  
was unable to. The debian kernel always put mmap areas either at the  
top of the address space or in the middle, depending on whether the  
stack size ulimit is finite or not.

After  further investigation, it seems that the behavior of smushing  
all the shared-library mappings down at the bottom, conflicting with  
the heap, is not in the upstream kernel, but is due to the execshield  
patch that Fedora adds. Looking at the patch here:

http://cvs.fedora.redhat.com/viewvc/devel/kernel/linux-2.6-execshield.patch?revision=1.90&view=markup

I see it makes mmap use "arch_get_unmapped_exec_area" (added in the  
patch) to get a free memory area if you call mmap with PROT_EXEC and  
(via arch_pick_mmap_layout) "if (!(current->personality &  
READ_IMPLIES_EXEC))".

And, arch_get_unmapped_exec_area starts filling from the bottom up.  
Also, despite it having a comment saying "Must not let a PROT_EXEC  
mapping get into the brk area", it appears that does sometimes happen,  
as well. And when it happens, it causes the heap to have no room to  
grow, thus breaking bash. Argh!

Although I'm not using the debian kernel or the debian execshield  
patch, I suspect this behavior is also present in the Debian  
execshield kernel patch but haven't verified.

This behavior was changed in Fedora CVS revision 1.103, with comment  
"Fix from H.J. Lu, we were doing 32-bit randomization on 64-bit  
vaddr". So the condition under which it will call  
arch_pick_mmap_layout now includes "mmap_is_ia32()". Thus it appears  
that on x86_64, the normal top-down stack layout will now be used for  
PROT_EXEC mappings as well, therefore leaving the heap plenty of room.

Given that I found that the behavior was a kernel bug not expected  
kernel behavior, that it wasn't ever in a "normal" kernel, and that  
it's apparently been fixed, I wouldn't be too upset to see this bug  
report result in no change to bash.

But I still think that the brain-damaged malloc included with bash  
would probably be better off disabled. Every other app can use mmap to  
get memory when sbrk runs out; bash was the only thing which sometimes  
failed.

James

Message #15 received at 522849-done@bugs.debian.org (full text, mbox, reply):

From: Gioele Barabucci <gioele@svario.it>

To: 522849-done@bugs.debian.org

Subject: Re: Bug#522849: Bash xrealloc randomly fails

Date: Mon, 1 Jul 2024 23:42:17 +0200

Version: 4.4.18-2

On Mon, 6 Apr 2009 18:25:05 -0400 James Y Knight <foom@fuhm.net> wrote:
> I believe this bug is due to Bash's builtin malloc implementation only  
> supporting sbrk() and not mmap() to get memory.

Since version 4.4.18-2 Debian's bash is compiled using 
--without-bash-malloc, so this error should not affect it anymore.

-- 
Gioele Barabucci

Send a report that this bug log contains spam.