Bug 98637 - bash/slocate segfaults when given lengthy single argument
Summary: bash/slocate segfaults when given lengthy single argument
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 8.0
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-07-06 12:22 UTC by D. Thomas
Modified: 2007-04-18 16:55 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2003-12-10 16:07:12 UTC


Attachments (Terms of Use)
gdb backtrace of core dump and /usr/bin/locate (5.85 KB, text/plain)
2003-07-06 12:27 UTC, D. Thomas
no flags Details

Description D. Thomas 2003-07-06 12:22:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516
Mozilla Firebird/0.6

Description of problem:
If /usr/bin/locate is executed with just one argument, that argument is
sufficiently long, and that argument consists of random character minus all
newlines and whitespaces, /usr/bin/locate will segmentation fault, and the
user's shell will automatically exit. (If in an xterm, the xterm will exit; if
in the proper console, one will be returned to the login prompt.)

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

How reproducible:
Always

Steps to Reproduce:
The following commandline:

locate `tr -d '\n\r\t ' < /dev/urandom | dd count=300 bs=300`

will generally be enough to trigger the segmentation fault.

Actual Results:  /usr/bin/locate exited with signal 11. Where possible, a core
dump is produced. On my system, when the steps to reproduce the error were
performed by root, the core file was approximately 9,200,000 to 9,210,000 bytes
in size.

Expected Results:  /usr/bin/locate should have simply displayed an error
informing the user that the argument was too long or contained invalid
characters and exited without core dumping. Alternatively, /usr/bin/locate could
have searched for the given argument in its database regardless.

Additional info:

Comment 1 D. Thomas 2003-07-06 12:27:10 UTC
Created attachment 92764 [details]
gdb backtrace of core dump and /usr/bin/locate

Probably not very informative, but just in case it helps, here's a backtrace.

Comment 2 D. Thomas 2003-07-06 12:49:17 UTC
Oops. This problem doesn't apply to slocate alone; I think it's a problem in
bash. I don't get the problem in ash. I've also managed to reproduce otherwise
identical problems for other programs, such as ls and man. Been looking in the
wrong place for a bug! Bash seems to have some problem when given a very long
single argument when processing the list of arguments for a program.

Comment 3 Tim Waugh 2003-07-07 08:09:38 UTC
Can you get a stack trace from bash?

Comment 4 Karsten Hopp 2003-07-16 12:19:38 UTC
[bash] >locate `tr -d '\n\r\t ' < /dev/urandom | dd count=300 bs=300` 
299+1 Records ein 
299+1 Records aus 
 
Program received signal SIGSEGV, Segmentation fault. 
0x080ce9cb in glob_filename ( 
    pathname=0xbf809140 
"\235.\026�׾pikFa\\\177ts\230+��226�\212�\b\232\bRs\026\223.7\203\200�221/zH\205!��\e�025\232x\235\211�\025\210g\004��\e-3T&\221\e|�224}G\036C�027\216p#il\032\226\227ڲ\\\177\207->~\004E\016#z�C�016)LyLu*\202mR9Q\211\206\\\200L\227�\027��235W�^e�\206�\234k\034�1M^��\vOi\217�213��I]\226�"..., 
flags=0) 
    at glob.c:655 
655           bcopy (pathname, directory_name, directory_len); 
(gdb) bt 
#0  0x080ce9cb in glob_filename ( 
    pathname=0xbf809140 
"\235.\026�׾pikFa\\\177ts\230+��226�\212�\b\232\bRs\026\223.7\203\200�221/zH\205!��\e�025\232x\235\211�\025\210g\004��\e-3T&\221\e|�224}G\036C�027\216p#il\032\226\227ڲ\\\177\207->~\004E\016#z�C�016)LyLu*\202mR9Q\211\206\\\200L\227�\027��235W�^e�\206�\234k\034�1M^��\vOi\217�213��I]\226�"..., 
flags=0) 
    at glob.c:655 
#1  0x080cea28 in glob_filename ( 
    pathname=0xbf819b20 
"\235.\026�׾pikFa\\\177ts\230+��226�\212�\b\232\bRs\026\223.7\203\200�221/zH\205!��\e�025\232x\235\211�\025\210g\004��\e-3T&\221\e|�224}G\036C�027\216p#il\032\226\227ڲ\\\177\207->~\004E\016#z�C�016)LyLu*\202mR9Q\211\206\\\200L\227�\027��235W�^e�\206�\234k\034�1M^��\vOi\217�213��I]\226�"..., 
flags=0) 
    at glob.c:670 
#2  0x080cea28 in glob_filename ( 
    pathname=0xbf82a5c0 
"\235.\026�׾pikFa\\\177ts\230+��226�\212�\b\232\bRs\026\223.7\203\200�221/zH\205!��\e�025\232x\235\211�\025\210g\004��\e-3T&\221\e|�224}G\036C�027\216p#il\032\226\227ڲ\\\177\207->~\004E\016#z�C�016)LyLu*\202mR9Q\211\206\\\200L\227�\027��235W�^e�\206�\234k\034�1M^��\vOi\217�213��I]\226�"..., 
flags=0) 
    at glob.c:670 
#3  0x080cea28 in glob_filename ( 
    pathname=0xbf83b100 
"\235.\026�׾pikFa\\\177ts\230+��226�\212�\b\232\bRs\026\223.7\203\200�221/zH\205!��\e�025\232x\235\211�\025\210g\004��\e-3T&\221\e|�224}G\036C�027\216p#il\032\226\227ڲ\\\177\207->~\004E\016#z�C�016)LyLu*\202mR9Q\211\206\\\200L\227�\027��235W�^e�\206�\234k\034�1M^��\vOi\217�213��I]\226�"..., 
flags=0) 
    at glob.c:670 
#4  0x080cea28 in glob_filename ( 
    pathname=0xbf84beb0 
"\235.\026�׾pikFa\\\177ts\230+��226�\212�\b\232\bRs\026\223.7\203\200�221/zH\205!��\e�025\232x\235\211�\025\210g\004��\e-3T&\221\e|�224}G\036C�027\216p#il\032\226\227ڲ\\\177\207->~\004E\016#z�C�016)LyLu*\202mR9Q\211\206\\\200L\227�\027��235W�^e�\206�\234k\034�1M^��\vOi\217�213��I]\226�"..., 
flags=0) 
    at glob.c:670 
#5  0x080cea28 in glob_filename ( 
    pathname=0xbf85ce20 
"\235.\026�׾pikFa\\\177ts\230+��226�\212�\b\232\bRs\026\223.7\203\200�221/zH\205!��\e�025\232x\235\211�\025\210g\004��\e-3T&\221\e|�224}G\036C�027\216p#il\032\226\227ڲ\\\177\207->~\004E\016#z�C�016)LyLu*\202mR9Q\211\206\\\200L\227�\027��235W�^e�\206�\234k\034�1M^��\vOi\217�213��I]\226�"..., 
flags=0) 
    at glob.c:670 
#6  0x080cea28 in glob_filename ( 
    pathname=0xbf86ddd0 
"\235.\026�׾pikFa\\\177ts\230+��226�\212�\b\232\bRs\026\223.7\203\200�221/zH\205!��\e�025\232x\235\211�\025\210g\004��\e-3T&\221\e|�224}G\036C�027\216p#il\032\226\227ڲ\\\177\207 
 

Comment 6 Tim Waugh 2003-07-16 16:37:10 UTC
I see it now.  Here's a better test case:

bash -c "echo `perl -e 'print \"*/\" x 4000'`"

It's an unbounded recursion.

Comment 7 Tim Waugh 2003-07-18 10:30:34 UTC
Reported upstream.

Comment 8 Tim Waugh 2003-12-10 16:07:12 UTC
Fixed upstream in 3.0alpha.


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