Bug 190469 - Buffer overflow abort in realpath() on FC5 glibc 2.4-4
Buffer overflow abort in realpath() on FC5 glibc 2.4-4
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-02 14:09 EDT by Ken Hall
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-03 08:29:22 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)
Test Program (688 bytes, text/plain)
2006-05-02 14:14 EDT, Ken Hall
no flags Details

  None (edit)
Description Ken Hall 2006-05-02 14:09:03 EDT
Description of problem:

Using certain compile options, realpath() function triggers buffer overflow 
abort.

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

Fedoda Core 5, glibc 2.4-4

How reproducible:

Options must be exactly correct, but once it fails, it fails every time.

Steps to Reproduce:
1. Compile the attached program using the following:

cc -o rptest2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-
protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=generic -
fasynchronous-unwind-tables rptest2.c
  
Actual results:
*** buffer overflow detected ***: ./rptest2 terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0x1dc965]
/lib/libc.so.6(__ptsname_r_chk+0x0)[0x1dcfa8]
./rptest2[0x80485e0]
/lib/libc.so.6(__libc_start_main+0xdc)[0x1167e4]
./rptest2[0x80484f1]
======= Memory map: ========
00101000-0022d000 r-xp 00000000 08:02 2433577    /lib/libc-2.4.so
0022d000-00230000 r-xp 0012b000 08:02 2433577    /lib/libc-2.4.so
00230000-00231000 rwxp 0012e000 08:02 2433577    /lib/libc-2.4.so
00231000-00234000 rwxp 00231000 00:00 0 
00531000-00532000 r-xp 00531000 00:00 0          [vdso]
00532000-0054b000 r-xp 00000000 08:02 2433576    /lib/ld-2.4.so
0054b000-0054c000 r-xp 00018000 08:02 2433576    /lib/ld-2.4.so
0054c000-0054d000 rwxp 00019000 08:02 2433576    /lib/ld-2.4.so
0611a000-06125000 r-xp 00000000 08:02 2433581    /lib/libgcc_s-4.1.0-
20060304.so.1
06125000-06126000 rwxp 0000a000 08:02 2433581    /lib/libgcc_s-4.1.0-
20060304.so.1
08048000-08049000 r-xp 00000000 08:02 422582     /home/ken/src/rptest2
08049000-0804a000 rw-p 00000000 08:02 422582     /home/ken/src/rptest2
09039000-0905a000 rw-p 09039000 00:00 0          [heap]
b7efa000-b7efb000 rw-p b7efa000 00:00 0 
b7f11000-b7f12000 rw-p b7f11000 00:00 0 
bf7fc000-bf811000 rw-p bf7fc000 00:00 0          [stack]
Aborted


Expected results:

Should print the same path as the input string:  "/usr/share/hercules"

Additional info:

The problem originally appeared in the Hercules mainframe emulator program, 
which explains the structure of the program and compile options.  I was able to 
duplicate it using the attached test program.  This is running on a Pentium M-
based Toshiba Laptop, 2 ghz., 512 mb. RAM, all latest package updates as of 
5/2/06.  It has also been seen under FC5 x86-64 on AMD X2 CPU.
Comment 1 Ken Hall 2006-05-02 14:14:19 EDT
Created attachment 128503 [details]
Test Program
Comment 2 Jakub Jelinek 2006-05-03 08:29:22 EDT
The testcase is buggy:
 -- Function: char * realpath (const char *restrict NAME, char
          *restrict RESOLVED)
     A call to `realpath' where the RESOLVED parameter is `NULL'
     behaves exactly like `canonicalize_file_name'.  The function
     allocates a buffer for the file name and returns a pointer to it.
     If RESOLVED is not `NULL' it points to a buffer into which the
     result is copied.  It is the callers responsibility to allocate a
     buffer which is large enough.  On systems which define `PATH_MAX'
     this means the buffer must be large enough for a pathname of this
     size.  For systems without limitations on the pathname length the
     requirement cannot be met and programs should not call `realpath'
     with anything but `NULL' for the second parameter.

On Linux, PATH_MAX is 4096, so your program violates that.

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