misc/77934: "ping6 -s 65528 ::1" results in a kernel-panic

[Gerd Rausch]

>Number:         77934
>Category:       misc
>Synopsis:       "ping6 -s 65528 ::1" results in a kernel-panic
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 22 20:00:35 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Gerd Rausch
>Release:        4.11
>Organization:
Juniper Networks
>Environment:
>Description:
root at propecia% ping6 -s 65528 ::1
PING6(65576=40+8p+65528 bytes) ::a1 --> ::1
nic: sbappendaddr
panic(c0528560,c0528560,c04945b8,e1e77b50,4) at panic+0x9d
panic(c04945b8,0,0,1000000,0) at panic+0x9d
sbappendaddr(deecad4c,e1e77bbc,c1bbf300,c1bbf300,c1bbf300,28,c1bbf3d0,c1bbf300) at sbappendaddr+0x2e
icmp6_rip6_input(e1e77c34,28,4d8,14,c1bbf300) at icmp6_rip6_input+0x247
icmp6_input(e1e77c98,e1e77d1c,3a,c1bfc2d8,c1bfc200) at icmp6_input+0x675
process_ipv6_headers(e1e77d3c,e1e77d40,3a,e1e77d1c,0) at process_ipv6_headers+0x17e
ip6_input(c69a9c00,c1bbf300,1,c0307403) at ip6_input+0x229
ip6intr(c04538ea,0,c0469c1e,deecad00,0) at ip6intr+0xb8
swi_net_next(deecad00,c68e2960,e1e77e28,c1c1ae00,0) at swi_net_next
sendit(e1d8fd40,3,e1e77eb8,0,806b3a0) at sendit+0x257
sendmsg(e1d8fd40,e1e77f68,c,c04609f4,e1e1f700) at sendmsg+0x98
syscall2(2f,2f,2f,bfbff6c0,10000) at syscall2+0x243
Xint0x80_syscall() at Xint0x80_syscall+0x25
Debugger("panic")
Stopped at      Debugger+0x55:  movl    $0xffffffff,0(%esp)
db> 


>How-To-Repeat:
ping6 -s 65528 ::1

>Fix:
The panic unveils two problems:

#1) ip6_output calls ip6_process_hopopts with
    two uninitialized variables "dummy1" & "dummy2".
    Unfortunately, ip6_process_hopopts checks
    "dummy2" of a non-zero value and regards that
    as an error, triggering a "icmp6_error" to be
    sent.

But that alone should not result in a kernel-panic, right?

#2) icmp6_notify_error uses IP6_EXTHDR_CHECK, which in
    turn calls m_pullup.
    Now (un)fortunately, m_pullup returns the new mbuf
    that is contiguous.
    Unfortunately, icmp6_notify_error continues to use the
    old pointer, which after the m_pullup is not suitable
    as a packet header any longer (see m_move_pkthdr).
    And this is what causes the kernel panic in sbappendaddr
    later on.


Here's a fix:

--- sys/netinet6/icmp6.c	Sun Mar 28 07:13:37 2004
+++ ../../x/src/sys/netinet6/icmp6.c	Tue Feb 22 11:26:44 2005
@@ -167,7 +167,7 @@ static int ni6_addrs __P((struct icmp6_n
 			  struct ifnet **, char *));
 static int ni6_store_addrs __P((struct icmp6_nodeinfo *, struct icmp6_nodeinfo *,
 				struct ifnet *, int));
-static int icmp6_notify_error __P((struct mbuf *, int, int, int));
+static int icmp6_notify_error __P((struct mbuf **, int, int, int));
 
 #ifdef COMPAT_RFC1885
 static struct route_in6 icmp6_reflect_rt;
@@ -846,7 +846,7 @@ icmp6_input(mp, offp, proto)
 			break;
 		}
 	deliver:
-		if (icmp6_notify_error(m, off, icmp6len, code)) {
+		if (icmp6_notify_error(&m, off, icmp6len, code)) {
 			/* In this case, m should've been freed. */
 			return(IPPROTO_DONE);
 		}
@@ -872,10 +872,11 @@ icmp6_input(mp, offp, proto)
 }
 
 static int
-icmp6_notify_error(m, off, icmp6len, code)
-	struct mbuf *m;
+icmp6_notify_error(mp, off, icmp6len, code)
+	struct mbuf **mp;
 	int off, icmp6len;
 {
+ 	struct mbuf *m = *mp;
 	struct icmp6_hdr *icmp6;
 	struct ip6_hdr *eip6;
 	u_int32_t notifymtu;
@@ -1114,6 +1115,7 @@ icmp6_notify_error(m, off, icmp6len, cod
 					  &ip6cp);
 		}
 	}
+	*mp = m;
 	return(0);
 
   freeit:
--- sys/netinet6/ip6_output.c	Sun Mar 28 07:11:57 2004
+++ ../../x/src/sys/netinet6/ip6_output.c	Tue Feb 22 11:25:08 2005
@@ -857,8 +857,8 @@ skip_ipsec2:;
 	 */
 	if (exthdrs.ip6e_hbh) {
 		struct ip6_hbh *hbh = mtod(exthdrs.ip6e_hbh, struct ip6_hbh *);
-		u_int32_t dummy1; /* XXX unused */
-		u_int32_t dummy2; /* XXX unused */
+		u_int32_t dummy1 = 0; /* XXX unused */
+		u_int32_t dummy2 = 0; /* XXX unused */
 
 #ifdef DIAGNOSTIC
 		if ((hbh->ip6h_len + 1) << 3 > exthdrs.ip6e_hbh->m_len)

>Release-Note:
>Audit-Trail:
>Unformatted: