From owner-freebsd-current@FreeBSD.ORG Sat Jul 18 16:41:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3D561065677 for ; Sat, 18 Jul 2009 16:41:55 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A4B5E8FC13 for ; Sat, 18 Jul 2009 16:41:55 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 0CFDE3BC2E7; Sat, 18 Jul 2009 12:41:55 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 18 Jul 2009 12:41:54 -0400 X-Sasl-enc: cngKlXwE9bXzwqCegIFrsi7Dnd1VerpMb7ZHDKMebbu2 1247935314 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 780F29BBD; Sat, 18 Jul 2009 12:41:54 -0400 (EDT) Message-ID: <4A61FB2A.3000304@incunabulum.net> Date: Sat, 18 Jul 2009 17:41:14 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: FreeBSD Current Content-Type: multipart/mixed; boundary="------------010205090207000808030401" Cc: re@FreeBSD.org Subject: [PATCH] Fix in6p_leave_group() panic by misbehaving apps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 16:41:56 -0000 This is a multi-part message in MIME format. --------------010205090207000808030401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, If anyone is experiencing panics with IPv6 in the kernel, and multicast applications active, please test this patch. I think some folk here saw this with VLC. re@: If this patch is good (I'll try to test locally) then it should go into HEAD ASAP. Some poorly behaved IPv6 multicast applications don't specify an interface for the join, and this triggers a KASSERT I put in to catch such corner cases. Multicast doesn't work unless apps are aware of the links active in the system they're running on, and this is a glaring hole in the Boost.ASIO API, sadly. This was caught by a Boost regression run on ref8.freebsd.org. Thanks to simon@ for logging the panic from the cluster console servers. cheers, BMS --------------010205090207000808030401 Content-Type: text/plain; name="8-current-v6-leave.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="8-current-v6-leave.diff" Index: in6_mcast.c =================================================================== --- in6_mcast.c (revision 195752) +++ in6_mcast.c (working copy) @@ -2166,8 +2166,23 @@ * refactored, assuming the scope IDs are the way to go. */ ifindex = ntohs(gsa->sin6.sin6_addr.s6_addr16[1]); +#if 0 KASSERT(ifindex != 0, ("%s: bad zone ID", __func__)); ifp = ifnet_byindex(ifindex); +#else + /* + * Some badly behaved applications don't pass an ifindex + * or a scope ID, which is an API violation. + */ + if (ifindex == 0) { + CTR2(KTR_MLD, "%s: warning: no ifindex, looking up " + "ifp for group %s.", __func__, + ip6_sprintf(ip6tbuf, &gsa->sin6.sin6_addr)); + ifp = in6p_lookup_mcast_ifp(inp, &gsa->sin6); + } else { + ifp = ifnet_byindex(ifindex); + } +#endif if (ifp == NULL) return (EADDRNOTAVAIL); } --------------010205090207000808030401--