Bug 160214 - bash segmentation fault on huge globs
bash segmentation fault on huge globs
Status: CLOSED DUPLICATE of bug 221381
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: bash (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Roman Rakus
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-13 11:30 EDT by Chris Snook
Modified: 2014-01-12 19:06 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-02 06:10:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Snook 2005-06-13 11:30:17 EDT
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):
bash-3.0-19.2

How reproducible:
Always

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 15:08:05 EST
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 06:10:50 EDT

*** 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.