netdev - Re: general protection fault in skb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-+KwmB+fX+4A1RiCV6ZCDQbkGGSVu8YVMrAGxfVtG7ndQ@mail.gmail.com>
Date:   Sun, 31 Dec 2017 10:52:14 +0100
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc:     syzbot <syzbot+fee64147a25aecd48055@...kaller.appspotmail.com>,
        David Miller <davem@...emloft.net>,
        LKML <linux-kernel@...r.kernel.org>, linux-sctp@...r.kernel.org,
        Network Development <netdev@...r.kernel.org>,
        Neil Horman <nhorman@...driver.com>,
        syzkaller-bugs@...glegroups.com,
        Vladislav Yasevich <vyasevich@...il.com>
Subject: Re: general protection fault in skb_segment

> It seems virtio_net could use more sanity checks. When PACKET_VNET_HDR
> is used, it will end up calling:
> tpacket_rcv() {
> ...
>         if (do_vnet) {
>                 if (virtio_net_hdr_from_skb(skb, h.raw + macoff -
>                                             sizeof(struct virtio_net_hdr),
>                                             vio_le(), true)) {
>                         spin_lock(&sk->sk_receive_queue.lock);
>                         goto drop_n_account;
>                 }
>         }
>
> and virtio_net_hdr_from_skb does:
>         if (skb_is_gso(skb)) {
> ...
>                 if (sinfo->gso_type & SKB_GSO_TCPV4)
>                         hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
>                 else if (sinfo->gso_type & SKB_GSO_TCPV6)
>                         hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
>                 else
>                         return -EINVAL;

That is the receive path, but the send path is analogous. Just adds
UFO.

> Meaning that any gso_type other than TCP would be rejected, but this
> SCTP one got through. Seems the header contains a sctp header, but the
> gso_type set was actually pointing to TCP (otherwise it would have
> been rejected). AFAICT if this packet had an ESP header, for example,
> it could have hit esp4_gso_segment. Can you please confirm this?

I have not tested this yet, but it certainly seems plausible.

There is nothing ensuring consistency between gso_type and
the actual packet contents that are parsed to look up gso callbacks.

> I don't know of anywhere in the stack validating if the gso_type
> matches the header that actually is in there.
>
> The fix you mentioned is a good start, we want that one way or
> another, but I'm afraid this bug is bigger than sctp.

Good point. Packet sockets require CAP_NET_RAW, but this is also
taken for virtio, so we probably want more stringent entry tests here.

The alternative to harden the segmentation code itself with a gso_type
sanity check in every gso callback is more work and fragile.

Need to figure out whether a brief check for just TCP or UDP is sufficient
or we need a full flow dissector step to support tunnel headers and such.