This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 98637 - bash/slocate segfaults when given lengthy single argument
bash/slocate segfaults when given lengthy single argument
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
8.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-06 08:22 EDT by D. Thomas
Modified: 2007-04-18 12:55 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-10 11:07:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description D. Thomas 2003-07-06 08:22:21 EDT
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 08:27:10 EDT
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 08:49:17 EDT
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 04:09:38 EDT
Can you get a stack trace from bash?
Comment 4 Karsten Hopp 2003-07-16 08:19:38 EDT
[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 12:37:10 EDT
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 06:30:34 EDT
Reported upstream.
Comment 8 Tim Waugh 2003-12-10 11:07:12 EST
Fixed upstream in 3.0alpha.

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