From owner-freebsd-bugs@FreeBSD.ORG Thu Jul 13 17:40:18 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 816B716A4DD for ; Thu, 13 Jul 2006 17:40:18 +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 8B9D443D58 for ; Thu, 13 Jul 2006 17:40:16 +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 k6DHeGGh097209 for ; Thu, 13 Jul 2006 17:40:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6DHeGWc097208; Thu, 13 Jul 2006 17:40:16 GMT (envelope-from gnats) Resent-Date: Thu, 13 Jul 2006 17:40:16 GMT Resent-Message-Id: <200607131740.k6DHeGWc097208@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Clément Lecigne Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E51316A4DD for ; Thu, 13 Jul 2006 17:33:39 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60A1143D69 for ; Thu, 13 Jul 2006 17:33:34 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k6DHXYuA033402 for ; Thu, 13 Jul 2006 17:33:34 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k6DHXYCe033400; Thu, 13 Jul 2006 17:33:34 GMT (envelope-from nobody) Message-Id: <200607131733.k6DHXYCe033400@www.freebsd.org> Date: Thu, 13 Jul 2006 17:33:34 GMT From: Clément Lecigne To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: kern/100219: IPV6_PKTOPTIONS and possible mbuf exhaustion. X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 17:40:18 -0000 >Number: 100219 >Category: kern >Synopsis: IPV6_PKTOPTIONS and possible mbuf exhaustion. >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Jul 13 17:40:15 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Clément Lecigne >Release: 6.1-STABLE >Organization: >Environment: FreeBSD pouik 6.1-STABLE FreeBSD 6.1-STABLE #12: Thu Jul 13 10:02:47 CEST 2006 clem1@pouik:/usr/obj/usr/src/sys/POUIK i386 >Description: When we call setsockopt() with IPV6_PKTOPTIONS and a huge optlen value, kernel will call soopt_getm(). This function will allocate plenty of mbuf (MGET), will hit the mbuf limit and will wait (M_TRYWAIT) until futher mbuf is available. At this point practically all mbuf are in use and networking applications may fail. A similar issue has been described by James Juran (pr98858). However the proposed patch fixes the integer overflow (which can be more dangerous than a simple dos) and does not prevent users to use a huge int value in the 5th argument of setsockopt() to cause the same behavior described by James (with optlen = -1). >How-To-Repeat: #include #include #include int main(int ac, char **av) { int s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); setsockopt(s, IPPROTO_IPV6, 25, 0xdeadbeef, 0x7fffffff); } >Fix: Since the RFC3542 has removed IPV6_PKTOPTIONS, userland applications must not use this option anymore. I have not found IPv6 networking applications (i.e. ping6, rtadvd) that continue to use IPV6_PKTOPTIONS. So I think we can remove this option. If not, we must put some limits on the sopt_valsize before calling soopt_getm(). >Release-Note: >Audit-Trail: >Unformatted: