hiho!

there exists an integer bug in the ipv6 implementation of the linux kernel.
(at least in 2.4.20 and 2.6.4 )
in /linux/net/ipv6/ipv6_sockglue.c:


int ipv6_setsockopt(struct sock *sk, int level, int optname, char *optval,
               int optlen)
{
        struct ipv6_pinfo *np = inet6_sk(sk);
        int val, valbool;
        int retv = -ENOPROTOOPT;

        if (level == SOL_IP && sk->sk_type != SOCK_RAW)
                return udp_prot.setsockopt(sk, level, optname, optval,optlen);

        if(level!=SOL_IPV6)
                goto out;

        if (optval == NULL)
                val=0;
        else if (get_user(val, (int *) optval))
                return -EFAULT;

        valbool = (val!=0);

        lock_sock(sk);

        switch (optname) {
 [...]

 case IPV6_PKTOPTIONS:
        {
                struct ipv6_txoptions *opt = NULL;
                struct msghdr msg;
                struct flowi fl;
                int junk;

                fl.fl6_flowlabel = 0;
                fl.oif = sk->sk_bound_dev_if;

[1]            if (optlen == 0)
                        goto update;

                /* 1K is probably excessive
                 * 1K is surely not enough, 2K per standard header is 16K.
                 */
                retv = -EINVAL;
[2]             if (optlen > 64*1024) 
                        break;

[3]            opt = sock_kmalloc(sk, sizeof(*opt) + optlen, GFP_KERNEL);
                retv = -ENOBUFS; sizeof(*opt)+0xfffffff8
                if (opt == NULL)
                        break;

[4]            memset(opt, 0, sizeof(*opt));
                opt->tot_len = sizeof(*opt) + optlen;
                retv = -EFAULT;
[5]            if (copy_from_user(opt+1, optval, optlen))
[...]

details:

condition [1] and [2] are easily passed for a value like -100, then at [3] 
sock_kmalloc allocates a too small object of the size (sizeof(*opt) + (-100))
which is then overflowed in [4] and [5] leading to a dos of the kernel...

that's it 
over and out!

-- 

-q/UNF