From dan@kulesh.obluda.cz  Tue Jul 12 19:19:01 2005
Return-Path: <dan@kulesh.obluda.cz>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 90A7F16A41C
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 12 Jul 2005 19:19:01 +0000 (GMT)
	(envelope-from dan@kulesh.obluda.cz)
Received: from kulesh.obluda.cz (kulesh.obluda.cz [193.179.22.243])
	by mx1.FreeBSD.org (Postfix) with ESMTP id C60C243D48
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 12 Jul 2005 19:18:57 +0000 (GMT)
	(envelope-from dan@kulesh.obluda.cz)
Received: from kulesh.obluda.cz (localhost.eunet.cz [127.0.0.1])
	by kulesh.obluda.cz (8.13.3/8.13.3) with ESMTP id j6CJItLR016653
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 12 Jul 2005 21:18:56 +0200 (CEST)
	(envelope-from dan@kulesh.obluda.cz)
Received: (from root@localhost)
	by kulesh.obluda.cz (8.13.3/8.13.1/Submit) id j6CJItCe016652;
	Tue, 12 Jul 2005 21:18:55 +0200 (CEST)
	(envelope-from dan)
Message-Id: <200507121918.j6CJItCe016652@kulesh.obluda.cz>
Date: Tue, 12 Jul 2005 21:18:55 +0200 (CEST)
From: Dan Lukes <dan@obluda.cz>
Reply-To: Dan Lukes <dan@obluda.cz>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [ PATCH ] improper handling of malloc failures within libc's vfprintf
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         83347
>Category:       bin
>Synopsis:       [patch] improper handling of malloc failures within libc's vfprintf
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 12 19:20:05 GMT 2005
>Closed-Date:    Mon Dec 17 07:18:57 UTC 2007
>Last-Modified:  Mon Dec 17 09:30:02 UTC 2007
>Originator:     Dan Lukes
>Release:        FreeBSD 5.4-STABLE i386
>Organization:
Obludarium
>Environment:
System: FreeBSD 5.4-STABLE #8: Sat Jul 9 16:31:08 CEST 2005 i386
lib/libc/stdio/vfprintf.c,v 1.67.2.1 2004/08/31 05:20:43 des

>Description:
	Improper handling of malloc failures within __find_arguments() - the
supporting function for vfprintf() - can cause dereferencing of NULL

>How-To-Repeat:
>Fix:

	The abort() is not the best way to handle this kind of failure, but it's the
same way as other function within the same source, the __grow_type_table()
handle it. abort() seems to be better than nothink.

--- patch begins here ---
--- lib/libc/stdio/vfprintf.c.ORIG	Tue Aug 31 07:20:43 2004
+++ lib/libc/stdio/vfprintf.c	Tue Jul 12 21:11:09 2005
@@ -1486,6 +1486,8 @@
 	if (tablemax >= STATIC_ARG_TBL_SIZE) {
 		*argtable = (union arg *)
 		    malloc (sizeof (union arg) * (tablemax + 1));
+		if (*argtable == NULL)
+			abort();			/* XXX handle better */
 	}
 
 	(*argtable) [0].intarg = 0;
--- patch ends here ---
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: das 
State-Changed-When: Mon Dec 17 07:14:28 UTC 2007 
State-Changed-Why:  
If malloc fails, the program will SIGBUS on the next line anyway, so 
there's no need to call abort(). This situation can only arise if the 
programmer has asked printf() to handle a very long and bizarre series 
of positional arguments after exhausting all available virtual memory, 
so hopefully this won't be a big deal. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=83347 

From: Dan Lukes <dan@obluda.cz>
To: das@freebsd.org
Cc: bug-followup@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: bin/83347: [patch] improper handling of malloc failures within
 libc's vfprintf
Date: Mon, 17 Dec 2007 10:26:04 +0100

 	Sure ?
 
 	Pointer value of 0 is nothing "magic" for hardware - it's legal to 
 write to memory offset 0 unless blocked by explicit configuration. It's 
 OS decision to block writes to offset 0. Are you sure it's true for all 
 supported platforms ? Yes, I know it's valid for i386/AMD. In advance - 
 did you tried in even on platforms that will be supported in the future ?
 
 	In my humble opinion, the one abort() in that special case, even if 
 just for sure, has value.
 
 > This situation can only arise if the
 > programmer has asked printf() to handle a very long and bizarre series
 > of positional arguments after exhausting all available virtual memory,
 > so hopefully this won't be a big deal.
 
 	It's normal that exceptions occur rare. Despite of it, the nice 
 programmers shall handle it.
 
 	As you just closed the case I understand your don't want discussion 
 about it. No problem - you are commiter - it's your sovereign decision.
 
 	Sincerely
 
 					Dan
 
>Unformatted:
