From owner-freebsd-bugs@FreeBSD.ORG Thu Jul 6 05:00:36 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5B3816A4DE for ; Thu, 6 Jul 2006 05:00:36 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7814243D45 for ; Thu, 6 Jul 2006 05:00:36 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6650afs055703 for ; Thu, 6 Jul 2006 05:00:36 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6650al8055701; Thu, 6 Jul 2006 05:00:36 GMT (envelope-from gnats) Date: Thu, 6 Jul 2006 05:00:36 GMT Message-Id: <200607060500.k6650al8055701@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Subject: Re: kern/99779: kernel panic due to Invlalid next packet identification in soreceive() X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2006 05:00:36 -0000 The following reply was made to PR kern/99779; it has been noted by GNATS. From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Maxim Konovalov 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 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.