Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 153003

Summary: free() reports spurious "free(): invalid pointer" warning when realloc fails and MALLOC_CHECK_=1
Product: [Fedora] Fedora Reporter: David Costanzo <david_costanzo>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 2CC: mattdm
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: 2.3.5-3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-28 20:43:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
realloctest.c -- a sample application that demonstrates the problem none

Description David Costanzo 2005-03-31 20:14:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217

Description of problem:
glibc has a special "always available" heap debugger that can be turned on by setting the "MALLOC_CHECK_" enviornment variable.  Its usage is explained on:

When MALLOC_CHECK_ is "1", free() prints a warning on this code:

  void * ptr = malloc(1);
  void * tmp = realloc(ptr, 0xFFFFFFFF);

In this case, the call to realloc() fails because there isn't 4GB of memory available.  When realloc() fails, the first argument is supposed to be unmodified.  This means that we must free it.  However, when free() is called, the following is printed:

  free(): invalid pointer 0x804a008!

I will attach a C program that does the same thing (with error checks).

Valgrind also reports an invalid memory free, so this may be a problem with the realloc() logic, not just the MALLOC_CHECK_ logic.

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

How reproducible:

Steps to Reproduce:
1. Compile realloctest.c
2. export MALLOC_CHECK_=1
3. ./realloctest.c

Actual Results:  The test print the following:

  malloc: using debugging hooks
  free(): invalid pointer 0x804a008!
  SUCCESS: realloc() correctly did nothing when asked to reallocate to 0xFFFFFFFF bytes

Expected Results:  It should print this: 

  malloc: using debugging hooks
  SUCCESS: realloc() correctly did nothing when asked to reallocate to 0xFFFFFFFF bytes

Additional info:

This is a contrived repro scenario.  In fact, I have only see this in contrived scenarios.  I often give programs invalid/malicious input to test how robust they are.  Sometimes, the invalid input is designed to force a large allocation.  Even when the program-under-test is implemented properly, MALLOC_CHECK_ and valgrind will signal a failure.  Because of this, I have filed may false bug reports.

If this problem were fixed, it would be easier to test for memory corruption.

Comment 1 David Costanzo 2005-03-31 20:18:49 UTC
Created attachment 112538 [details]
realloctest.c -- a sample application that demonstrates the problem

Comment 2 David Costanzo 2005-03-31 23:27:12 UTC
Someone just pointed out to me that I was using an old verson of valgrind.  The
latest valgrind (version 2.4.0) does NOT print out an error message for
realloctest.c.  Instead, it prints out a very reasonable message:

  ==9875== Warning: silly arg (-1) to realloc()

So this probably IS just a problem with the MALLOC_CHECK_ code, and not
realloc() overall.

Comment 3 Matthew Miller 2005-04-26 16:08:47 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 4 David Costanzo 2005-04-27 00:41:58 UTC
This is NOT a security issue.

I will post back when I have been able to test this on FC3 or FC4.

Comment 5 Jakub Jelinek 2005-04-28 20:43:10 UTC
Should be fixed in glibc-2.3.5-3 and later in rawhide.