From dima@unixfreak.org  Thu Apr 12 01:05:23 2001
Return-Path: <dima@unixfreak.org>
Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138])
	by hub.freebsd.org (Postfix) with ESMTP id D0B9E37B617
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 12 Apr 2001 01:05:20 -0700 (PDT)
	(envelope-from dima@unixfreak.org)
Received: from hornet.unixfreak.org (hornet [63.198.170.140])
	by bazooka.unixfreak.org (Postfix) with ESMTP id 47DB13E2A
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 12 Apr 2001 01:05:18 -0700 (PDT)
Received: (from dima@localhost)
	by hornet.unixfreak.org (8.11.1/8.11.1) id f3C85IH90584;
	Thu, 12 Apr 2001 01:05:18 -0700 (PDT)
	(envelope-from dima)
Message-Id: <200104120805.f3C85IH90584@hornet.unixfreak.org>
Date: Thu, 12 Apr 2001 01:05:18 -0700 (PDT)
From: dd@freebsd.org
Reply-To: dd@freebsd.org
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [PATCH] Obscure sysinstall NULL dereference bug
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         26509
>Category:       misc
>Synopsis:       [PATCH] Obscure sysinstall NULL dereference bug
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    dd
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 12 01:10:01 PDT 2001
>Closed-Date:    Mon Jul 23 03:10:13 PDT 2001
>Last-Modified:  Mon Jul 23 03:10:31 PDT 2001
>Originator:     Dima Dorfman
>Release:        FreeBSD 5.0-20010407-CURRENT i386
>Organization:
Private
>Environment:
System: FreeBSD spike.unixfreak.org 5.0-20010407-CURRENT FreeBSD 5.0-20010407-CURRENT #39: Sun Apr 8 22:44:22 PDT 2001 dima@spike.unixfreak.org:/c/home/dima/w/f/src/sys/compile/SPIKE i386

>Description:

On some occasions, sysinstall can be persuaded to follow a NULL
pointer.  This particular bug is actually not so straight-forward that
many people would run into it, but it seems I always do :-/ (I've had
this bite me for just about every release since 4.0 or so).

The problem is that a lot of code in sysinstall (dist.c, particuarly)
expects the mediaDevice global variable to be non-NULL.  When some
operation fails, you might see code like:

        mediaDevice->shutdown(mediaDevice);
        if (!mediaDevice->init(mediaDevice))
                ...

The problem is that sometimes the operation that fails sets
mediaDevice to NULL, causing a nice, annoying NULL dereference.

>How-To-Repeat:

 1. Run sysinstall in whatever mode you want; doesn't matter if it's
    on an existing system or not.  Somehow get to the part where you
    choose which distributions you want, choose at least one, then somehow
    get to the part where it will extract the distributions

 2. Choose an FTP install.  Select ftp.freebsd.org (you can use any
    server you want; I'm just using that as an example).

 3. Let it start extracting distributions.  Allow it to extract at
    least one file (i.e., let it do something).  At this point, cut off
    its link to the FTP server.  If this is an existing system,
    `ipfw add 1 reset tcp from any to ftp.freebsd.org` works nicely.  In
    practice, it can be any reason (I've had this happen when I chose "FTP"
    instead of "FTP passive" or when the Internet link died).

 4. Wait for it to figure out the server is dead.  It should prompt
    you to select another one.  At the "Please select a FreeBSD FTP
    distribution site" menu, select Cancel (you'd do this if, e.g., you
    wanted to switch from "FTP" to "FTP passive").

 5. Push "OK" or "yes" on the dialog boxes it presents.

 6. Watch it crash (if this is a new install where sysinstall is
    acting as init, it will display a nice "I got sigsegv and that's bad"
    message).

As you can deduce from the size of the instructions, few people
probably run into this.  Nevertheless, I think that for sysinstall,
anything short of corruption is better than crashing; the latter is
very annoying, esp. after you've spent some time deciding on the
filesystem layout, distributions, packages, etc.

>Fix:

The patch below corrects the problem by removing the
"mediaDevice = NULL" assignment from the mediaClose routine.  It's
not the most correct or elegant fix in the world, but too much code
assumes mediaDevice is non-NULL to simply go through and fix all of it.
At least it's the least intrusive fix I could come up with.

Index: media.c
===================================================================
RCS file: /st/src/FreeBSD/src/usr.sbin/sysinstall/media.c,v
retrieving revision 1.112
diff -u -r1.112 media.c
--- media.c	2000/09/25 20:19:43	1.112
+++ media.c	2001/04/12 00:01:24
@@ -126,7 +126,6 @@
 {
     if (mediaDevice)
 	mediaDevice->shutdown(mediaDevice);
-    mediaDevice = NULL;
 }
 
 /*

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->jkh 
Responsible-Changed-By: roam 
Responsible-Changed-When: Thu Apr 12 01:40:41 PDT 2001 
Responsible-Changed-Why:  
Over to sysinstall maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26509 
Responsible-Changed-From-To: jkh->dd 
Responsible-Changed-By: dd 
Responsible-Changed-When: Thu May 24 17:21:15 PDT 2001 
Responsible-Changed-Why:  
I'll commit the patch we talked about once I can test an install using the new 
code (few days). 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26509 
State-Changed-From-To: open->analyzed 
State-Changed-By: dd 
State-Changed-When: Sun Jul 1 17:31:09 PDT 2001 
State-Changed-Why:  
mfc reminder 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26509 
State-Changed-From-To: analyzed->closed 
State-Changed-By: dd 
State-Changed-When: Mon Jul 23 03:10:13 PDT 2001 
State-Changed-Why:  
DEVICE_* macros MFC'd 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26509 
>Unformatted:
