From jinmei@opera.isl.rdc.toshiba.co.jp  Tue Jul  4 12:12:26 2006
Return-Path: <jinmei@opera.isl.rdc.toshiba.co.jp>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1239916A4E7
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  4 Jul 2006 12:12:26 +0000 (UTC)
	(envelope-from jinmei@opera.isl.rdc.toshiba.co.jp)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A287843D5C
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  4 Jul 2006 12:12:25 +0000 (GMT)
	(envelope-from jinmei@opera.isl.rdc.toshiba.co.jp)
Received: from opera.isl.rdc.toshiba.co.jp (localhost [::1])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5EF2815267
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  4 Jul 2006 21:12:23 +0900 (JST)
Received: (from jinmei@localhost)
	by opera.isl.rdc.toshiba.co.jp (8.13.6/8.13.4/Submit) id k64CCMtE000910;
	Tue, 4 Jul 2006 21:12:22 +0900 (JST)
	(envelope-from jinmei)
Message-Id: <200607041212.k64CCMtE000910@opera.isl.rdc.toshiba.co.jp>
Date: Tue, 4 Jul 2006 21:12:22 +0900 (JST)
From: JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp>
Reply-To: JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: kernel panic due to Invlalid next packet identification in soreceive()
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         99779
>Category:       kern
>Synopsis:       kernel panic due to Invlalid next packet identification in soreceive()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnn
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 04 12:20:23 GMT 2006
>Closed-Date:    Mon Sep 18 11:24:38 GMT 2006
>Last-Modified:  Thu Aug 23 18:20:02 GMT 2007
>Originator:     JINMEI Tatuya
>Release:        FreeBSD 6.1-RELEASE-p2 i386
>Organization:
Toshiba Corporation / KAME Project
>Environment:
System: FreeBSD opera.isl.rdc.toshiba.co.jp 6.1-RELEASE-p2 FreeBSD 6.1-RELEASE-p2 #2: Tue Jul 4 20:29:29 JST 2006 jinmei@opera.isl.rdc.toshiba.co.jp:/local/usr.local/freebsd/src/sys/i386/compile/GENERIC i386


Intel Pentium 4 1.7GHZ, FreeBSD 6.1R, no particular patch
>Description:
If an AF_INET6 socket receives an empty packet with ancillary data
object, soreceive() will point to a bogus place in the socket buffer,
which can subsequenlty causes kernel panic.  Such an empty packet
can be sent to the socket by the use of the IPv6 IPV6_RECVPATHMTU
socket option.

Any non-privileged user can (potentially) trigger this bug.
	
>How-To-Repeat:
Compile the following code, set the MTU of the loopback interface
to some small value (e.g., 1500) by
# ifconfig lo0 mtu 1500
and then run this program.

#include <sys/types.h>
#include <sys/socket.h>

#include <netinet/in.h>

#include <netdb.h>

main() {
	int cc, s, on, error;
	char buf[4096];
	struct addrinfo *res, hints;
	struct sockaddr_in6 from;
	socklen_t fromlen;

	memset(&hints, 0, sizeof(hints));
	hints.ai_family = AF_INET6;
	hints.ai_socktype = SOCK_DGRAM;
	hints.ai_protocol = IPPROTO_UDP;
	getaddrinfo("::1", "5000", &hints, &res);
	s = socket(res->ai_family, res->ai_socktype, res->ai_protocol);

	on = 1;
	if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on))
	    != 0) {
		perror("setsockopt(IPV6_RECVPATHMTU)");
		exit(1);
	}

	on = 1;
	if (setsockopt(s, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(on)) != 0) {
		perror("setsockopt(IPV6_DONTFRAG)");
		exit(1);
	}

	if (bind(s, res->ai_addr, res->ai_addrlen) < 0) {
		perror("bind");
		exit(1);
	}

	cc = sendto(s, buf, sizeof(buf), 0, res->ai_addr, res->ai_addrlen);
	if (cc < 0)
		perror("sendto");

	fromlen = sizeof(from);
	cc = recvfrom(s, buf, sizeof(buf), 0, (struct sockaddr *)&from,
	    &fromlen);
	if (cc < 0)
		perror("recvfrom");

	exit(0);
}

>Fix:

A patch that fixes the problem is attached below.  FreeBSD 5.x also seems
to have the same bug.

--- uipc_socket.c	Tue Jul  4 20:29:16 2006
+++ uipc_socket.c.new	Mon Jul  3 14:04:42 2006
@@ -1169,7 +1169,10 @@
 			}
 			cm = cmn;
 		}
-		nextrecord = so->so_rcv.sb_mb->m_nextpkt;
+		if (m != NULL)
+			nextrecord = so->so_rcv.sb_mb->m_nextpkt;
+		else
+			nextrecord = so->so_rcv.sb_mb;
 		orig_resid = 0;
 	}
 	if (m != NULL) {

>Release-Note:
>Audit-Trail:

From: Maxim Konovalov <maxim@macomnet.ru>
To: JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp>
Cc: bug-followup@freebsd.org
Subject: Re: kern/99779: kernel panic due to Invlalid next packet identification
 in soreceive()
Date: Tue, 4 Jul 2006 17:03:30 +0400 (MSD)

 Hello,
 
 Could you please update your system to RELENG_6 branch and check if
 this fix the problem you describe?  gnn@ MFC'ed a similar fix there as
 part of kern/83885 work a couple of weeks ago (uipc_socket.c
 rev. 1.243 in HEAD and rev. 1.242.2.5 in RELENG_6).
 
 Thanks!
 
 -- 
 Maxim Konovalov

From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: Maxim Konovalov <maxim@macomnet.ru>
Cc: bug-followup@freebsd.org
Subject: Re: kern/99779: kernel panic due to Invlalid next packet identification in soreceive()
Date: Thu, 06 Jul 2006 13:57:55 +0900

 >>>>> On Tue, 4 Jul 2006 17:03:30 +0400 (MSD), 
 >>>>> Maxim Konovalov <maxim@macomnet.ru> said:
 
 > Could you please update your system to RELENG_6 branch and check if
 > this fix the problem you describe?  gnn@ MFC'ed a similar fix there as
 > part of kern/83885 work a couple of weeks ago (uipc_socket.c
 > rev. 1.243 in HEAD and rev. 1.242.2.5 in RELENG_6).
 
 Thanks for the prompt response.  I've not noticed the rev-1.243 fix (I
 should have checked the repository history more closely...), but in
 any event I don't think the change in that revision is really correct.
 (I've not upgraded the entire kernel to RELENG_6, but applied the patch
 introduced in rev. 1.243 and confirmed the problem described below).
 
 In fact, it does not catch the case where the socket buffer has two
 "packets": one that only consists of control mbufs and the other that
 follows the control-only packet.  In this case, m = NULL, but
 so->so_rcv.sb_mb is not because sockbuf_pushsync() after the do-while
 loop sets sb_mb to the original 'nextrecord'.  Then the RELENG_6 code
 sets nextrecord to NULL (sb_mb->m_nextpkt) at this point:
 
 		if (so->so_rcv.sb_mb != NULL)
 			nextrecord = so->so_rcv.sb_mb->m_nextpkt;
 
 while nextrecord should actually be so->so_rcv.sb_mb.
 
 This discrepancy subsequently causes socket buffer inconsistency at
 the following point of the code:
 
 			/*
 			 * First part is an inline SB_EMPTY_FIXUP().  Second
 			 * part makes sure sb_lastrecord is up-to-date if
 			 * there is still data in the socket buffer.
 			 */
 			so->so_rcv.sb_mb = nextrecord;
 			if (so->so_rcv.sb_mb == NULL) {
 				so->so_rcv.sb_mbtail = NULL;
 				so->so_rcv.sb_lastrecord = NULL;
 			} else if (nextrecord->m_nextpkt == NULL)
 
 that is, sb_mb is set to NULL even though there is an unreceived
 packet in the socket.  This will eventually cause a kernel panic.
 
 Using the problem description in kern/83885, this bug can be revealed
 by "ping6 -m -s 1300 -v PC2" (i.e., adding -v).  Then the ICMPv6 Too
 Big message follows the control mbuf and reproduced the situation
 described above.
 
 On the other hand, my patch correctly fixes both the problems.
Responsible-Changed-From-To: freebsd-bugs->gnn 
Responsible-Changed-By: maxim 
Responsible-Changed-When: Thu Jul 6 06:11:15 UTC 2006 
Responsible-Changed-Why:  
George, could you please look at the issue?  It is related to 
kern/83885 but has a different patch. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=99779 
State-Changed-From-To: open->feedback 
State-Changed-By: gnn 
State-Changed-When: Fri Aug 18 20:57:38 UTC 2006 
State-Changed-Why:  
Fixed in HEAD.  Please let me know if there are other problems with this patch. 

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

From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: "George V. Neville-Neil" <gnn@FreeBSD.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/99779: kernel panic due to Invlalid next packet identification in soreceive()
Date: Sat, 19 Aug 2006 13:33:45 +0900

 >>>>> On Fri, 18 Aug 2006 20:59:10 GMT, 
 >>>>> "George V. Neville-Neil" <gnn@FreeBSD.org> said:
 
 > Fixed in HEAD.  Please let me know if there are other problems with this patch.
 
 Thanks, this fix looks correct.  Please feel free to close this
 report.
 
 					JINMEI, Tatuya
 					Communication Platform Lab.
 					Corporate R&D Center, Toshiba Corp.
 					jinmei@isl.rdc.toshiba.co.jp
State-Changed-From-To: feedback->closed 
State-Changed-By: gnn 
State-Changed-When: Mon Sep 18 11:23:09 UTC 2006 
State-Changed-Why:  
Closed now that it is fixed, verified by the reporter, and MFC'd. 

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

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/99779: commit references a PR
Date: Thu, 23 Aug 2007 18:17:17 +0000 (UTC)

 jinmei      2007-08-23 18:17:08 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sys/kern             uipc_socket.c 
   Log:
   MFC:
     Fix a kernel panic based on receiving an ICMPv6 Packet too Big message.
     (MFC was planned but has been missed)
   
   PR:             99779
   Submitted by:   Jinmei Tatuya
   Reviewed by:    clement, rwatson
   Approved by:    gnn (mentor)
   
   src/sys/kern/uipc_socket.c:     1.280
   
   Revision    Changes    Path
   1.242.2.10  +2 -2      src/sys/kern/uipc_socket.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
>Unformatted:
