Bug 160214 - bash segmentation fault on huge globs
Summary: bash segmentation fault on huge globs
Status: CLOSED DUPLICATE of bug 221381
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: bash
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Roman Rakus
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-13 15:30 UTC by Chris Snook
Modified: 2014-01-13 00:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-06-02 10:10:50 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Chris Snook 2005-06-13 15:30:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Red Hat/1.0.4-1.4.1 Firefox/1.0.4

Description of problem:
Bash version 3.0 and 2.05b use alloca() to store the linked list structure that includes pointers to the malloc()ed strings of filenames that match a globbing pattern.  Since alloca() makes an unchecked allocation of stack memory, this can cause a stack overflow.  While version 3.0 includes a null check on the returned pointer, this check doesn't actually check for a failed allocation, since alloca() won't return null even if it overflows the stack.  While both versions return the expected "Argument list too long" error for large globs, they overflow the stack and segfault before hitting this check for extremely large globs.  The size of the glob required to trigger the overflow is version-dependent, and probably architecture-dependent due to how alloca() is compiled.  Adjusting the stack size from the ulimit default of 10MB will change the number of glob matches required to trigger a segfault.  On my testing on RHEL 4 x86, the number is around 380,000.  On RHEL 3 x86 (bash 2.05b) the number is around 600,000-700,000.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. for i in `seq 1 400000`; do touch $i; done
2. rm *

Actual Results:  Bash exited on signal 11.

Expected Results:  Bash should have said "Argument list too long."

Additional info:

This bug probably affects all recent versions of GNU Bash on all architectures and distributions.  It does not seem to affect ksh, tcsh, or zsh.

The bug could be mitigated by calculating command line length during the matching process, but using a more intelligent memory allocation scheme would probably be no more work.  While alloca() is ostensibly faster, the overhead it introduces and the inherent wastefulness of allocating a linked list one node at a time in a manner guaranteed to be sequential in memory probably eliminates any such benefit in the cases where it will take long enough for performance to be noticeable.

Comment 1 Josh Bressers 2006-02-15 20:08:05 UTC
It's worth noting that setting 'ulimit -s unlimited' makes this issue go away. 
I do admit this probably isn't proper behavior though.

Comment 2 Roman Rakus 2008-06-02 10:10:50 UTC

*** This bug has been marked as a duplicate of 221381 ***

Note You need to log in before you can comment on or make changes to this bug.