From mpp@mpp.com  Sun Jul  2 20:44:40 1995
Received: from mpp.com (mpp.Minn.Net [204.157.201.242])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA18709
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 2 Jul 1995 20:44:37 -0700
Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id WAA00385; Sun, 2 Jul 1995 22:43:49 -0500
Message-Id: <199507030343.WAA00385@mpp.com>
Date: Sun, 2 Jul 1995 22:43:49 -0500
From: mpp@legarto.minn.net
Reply-To: mpp@legarto.minn.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: rejecting packets w/ipfw can still panic machine
X-Send-Pr-Version: 3.2

>Number:         585
>Category:       kern
>Synopsis:       rejecting packets w/ipfw can still panic machine
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs (FreeBSD bugs mailing list)
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jul  2 20:50:04 1995
>Closed-Date:    Sun Jul 9 17:37:47 PDT 1995
>Last-Modified:
>Originator:     Mike Pritchard
>Release:        FreeBSD 2.0-BUILT-19950628 i386
>Organization:
>Environment:

>Description:

The recent change that went in to make packets rejected by ipfw
not panic the machine doesn't work in all cases.  The original
fix left 3 end cases where an attempt would be made to free
an mbuf with an uninitialized pointer, resulting in a machine panic.
I noticed this after building a kernel an noticing the following
warning messages:

In file included from ../../netinet/ip_fw.c:41:
../../../include/arpa/inet.h:50: warning: redundant redeclaration of `inet_ntoa' in same scope
../../netinet/in.h:259: warning: previous declaration of `inet_ntoa'
../../netinet/ip_fw.c: In function `ip_fw_chk':
../../netinet/ip_fw.c:114: warning: `m' might be used uninitialized in this function

>How-To-Repeat:

ipfw addf reject icmp from localhost
ping localhost
*panic*

>Fix:
	
The following fix eliminates the warning about inet_ntoa being
declared twice and fixes the ipfw panic problem.  The panic was
resolved by correctly initializing the mbuf pointer before all cases
where it is used.

*** orig/ip_fw.c	Sun Jul  2 22:36:28 1995
--- ip_fw.c	Sun Jul  2 22:27:31 1995
***************
*** 37,45 ****
  #include <netinet/tcp.h>
  #include <netinet/udp.h>
  #include <netinet/ip_icmp.h>
- 
- #include <arpa/inet.h>
- 
  #include <netinet/ip_fw.h>
  
  #ifdef IPFIREWALL_DEBUG
--- 37,42 ----
***************
*** 303,308 ****
--- 300,306 ----
  #endif
  
  bad_packet:
+ 	m = dtom(ip);
  	if (f) {
  			/*
  			 * Do not ICMP reply to icmp
***************
*** 317,323 ****
  			 */
  		if (!(f->fw_flg&IP_FW_F_ICMPRPL))
  			goto return_0;
- 		m = dtom(ip);
  		if (f_prt==IP_FW_F_ALL)
     			icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, 0L, 0);
  		else
--- 315,320 ----
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: davidg 
State-Changed-When: Sun Jul 9 17:37:47 PDT 1995 
State-Changed-Why:  
The bug was fixed with patches from Bill Fenner. 
>Unformatted:



