Date: Thu, 13 Jul 2006 17:33:34 GMT From: Clément Lecigne <clemun@gmail.com> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/100219: IPV6_PKTOPTIONS and possible mbuf exhaustion. Message-ID: <200607131733.k6DHXYCe033400@www.freebsd.org> Resent-Message-ID: <200607131740.k6DHeGWc097208@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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 <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607131733.k6DHXYCe033400>