Date: Thu, 6 Jul 2006 05:00:36 GMT From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/99779: kernel panic due to Invlalid next packet identification in soreceive() Message-ID: <200607060500.k6650al8055701@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR kern/99779; it has been noted by GNATS.
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.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607060500.k6650al8055701>