From jmaslak@blackfire.com  Wed Mar 12 09:58:16 1997
Received: from blackfire.com (hill153.uwyo.edu [129.72.150.153])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29042
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Mar 1997 09:58:08 -0800 (PST)
Received: (from jmaslak@localhost) by blackfire.com (8.8.5/8.7.3) id KAA21827; Wed, 12 Mar 1997 10:58:29 -0700 (MST)
Message-Id: <199703121758.KAA21827@blackfire.com>
Date: Wed, 12 Mar 1997 10:58:29 -0700 (MST)
From: Joel Maslak <jmaslak@blackfire.com>
Reply-To: jmaslak@blackfire.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: malloc() returns non-null when it should not
X-Send-Pr-Version: 3.2

>Number:         2964
>Category:       kern
>Synopsis:       malloc() returns non-null when it should not
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 12 10:00:01 PST 1997
>Closed-Date:    Mon Mar 17 23:54:35 PST 1997
>Last-Modified:  Mon Mar 17 23:54:53 PST 1997
>Originator:     Joel Maslak
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
None
>Environment:

	3.0-CURRENT from December 1996, Pentium, 32 MB RAM, 96 MB swap
	Ulimit set to 64 MB data size.

>Description:

	I'm assuming this is a kernel problem, although it may be a gnu
	problem.

	If malloc is called as follows:
		malloc((size_t) 0xffffffff)
	it returns a non-null pointer.  Obviously, free objects to
	freeing this storage, with a:
		Malloc warning: free():junk pointer, too high to make sense
	Thus, something is definately broke here.  The pointer allocated
	in this case has a value of 0x4000.

>How-To-Repeat:

	Compile (with GCC) and run:

	#include <stdlib.h>
	#include <stdio.h>

	int main(void) {
		void * p;
		p = malloc((size_t) 0xffffffff);
		if (p != NULL)
			printf("KERNEL BUG! %p\n", p);
		return 0;
	}

	Other values to try:
		0xffffb001 -> 0xfffff000 (Causes a segmentation fault,
					  inside malloc())
		0xfffff001 -> 0xffffffff (non-null return value)

>Fix:
	
	Don't use malloc.  :)

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, jmaslak@blackfire.com
Cc:  Subject: Re: kern/2964: malloc() returns non-null when it should not
Date: Thu, 13 Mar 1997 05:57:13 +1100

 >	I'm assuming this is a kernel problem, although it may be a gnu
 >	problem.
 >
 >	If malloc is called as follows:
 >		malloc((size_t) 0xffffffff)
 >	it returns a non-null pointer.  Obviously, free objects to
 
 Actually, it's just an overflow bug in the malloc library.  Rounding up
 of any size > 0xfffff000 to a page boundary gives a size of 0.  This
 bug is common in roundup macros.
 
 Bruce

From: Poul-Henning Kamp <phk@critter.dk.tfs.com>
To: jmaslak@blackfire.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/2964: malloc() returns non-null when it should not 
Date: Wed, 12 Mar 1997 21:08:23 +0100

 >	I'm assuming this is a kernel problem, although it may be a gnu
 >	problem.
 >
 >	If malloc is called as follows:
 >		malloc((size_t) 0xffffffff)
 >	it returns a non-null pointer.
 
 This is a sign extension problem in malloc() which I have not gotten
 around to fix properly.  It's on my "known but mostly harmless" list.
 
 malloc isn't a kernel function btw, it lives in libc.
 
 --
 Poul-Henning Kamp           | phk@FreeBSD.ORG       FreeBSD Core-team.
 http://www.freebsd.org/~phk | phk@login.dknet.dk    Private mailbox.
 whois: [PHK]                | phk@tfs.com           TRW Financial Systems, Inc.
 Power and ignorance is a disgusting cocktail.

From: Poul-Henning Kamp <phk@critter.dk.tfs.com>
To: jmaslak@blackfire.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/2964: malloc() returns non-null when it should not 
Date: Thu, 13 Mar 1997 09:52:01 +0100

 Try this patch: 
 
 Index: malloc.c
 ===================================================================
 RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.c,v
 retrieving revision 1.18.2.1
 diff -u -r1.18.2.1 malloc.c
 --- malloc.c	1996/12/30 01:35:15	1.18.2.1
 +++ malloc.c	1997/03/13 08:47:01
 @@ -731,7 +731,9 @@
      if (suicide)
  	abort();
  
 -    if (size <= malloc_maxsize)
 +    if ((size + malloc_pagesize) < size)	/* Check for overflow */
 +	result = 0;
 +    else if (size <= malloc_maxsize)
  	result =  malloc_bytes(size);
      else
  	result =  malloc_pages(size);
 
 --
 Poul-Henning Kamp           | phk@FreeBSD.ORG       FreeBSD Core-team.
 http://www.freebsd.org/~phk | phk@login.dknet.dk    Private mailbox.
 whois: [PHK]                | phk@tfs.com           TRW Financial Systems, Inc.
 Power and ignorance is a disgusting cocktail.

From: Joel Maslak <j@pobox.com>
To: Poul-Henning Kamp <phk@critter.dk.tfs.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/2964: malloc() returns non-null when it should not 
Date: Mon, 17 Mar 1997 19:57:08 -0700 (MST)

 On Thu, 13 Mar 1997, Poul-Henning Kamp wrote:
 
 Paul: Sorry about the previous message, it was an error on my part.
 
 > Try this patch: 
 > 
 > Index: malloc.c
 > ===================================================================
 > RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.c,v
 
 <I have the patch if needed, but Paul wrote it, so ask him.  :) >
 
 This patch worked perfectly.  I patched it into a 2.2-GAMMA system with
 absolutely no problems.  I could not get my library sources for 3.0 to
 compile cleanly, but I think that was due to when I grabbed them.
 
 I would consider this issue closed if we put this patch in. :)
 
 
 Joel Maslak
 
 Caution: When copying and pasting text, work with only a few lines
 at a time.  If you copy too many lines, you may trigger a bug in the
 system, and your window will become unstable.
 	Pg. 129, "A Practical Guide to the Unix System"
 
 
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Mon Mar 17 23:54:35 PST 1997 
State-Changed-Why:  
committed. 
>Unformatted:
