kern/100219: IPV6_PKTOPTIONS and possible mbuf exhaustion.

[Clément Lecigne]

>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 at 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: