From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: syzbot <syzbot+fee64147a25aecd48055@syzkaller.appspotmail.com>, David Miller <davem@davemloft.net>, LKML <linux-kernel@vger.kernel.org>, linux-sctp@vger.kernel.org, Network Development <netdev@vger.kernel.org>, Neil Horman <nhorman@tuxdriver.com>, syzkaller-bugs@googlegroups.com, Vladislav Yasevich <vyasevich@gmail.com> Subject: Re: general protection fault in skb_segment Date: Tue, 2 Jan 2018 16:48:17 +0100 [thread overview] Message-ID: <CAF=yD-K9M1yps+SogVLSVgoi+ngKzKrwWH+xMr4-m+v-pqyXXQ@mail.gmail.com> (raw) In-Reply-To: <CAF=yD-+KwmB+fX+4A1RiCV6ZCDQbkGGSVu8YVMrAGxfVtG7ndQ@mail.gmail.com> > Good point. Packet sockets require CAP_NET_RAW, but this is also > taken for virtio, so we probably want more stringent entry tests here. That would be something like #include <linux/if_vlan.h> +#include <linux/skbuff.h> #include <uapi/linux/virtio_net.h> +#include <net/flow_dissector.h> static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, const struct virtio_net_hdr *hdr, @@ -12,14 +14,27 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, unsigned int gso_type = 0; if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) { + struct flow_keys flow = { .basic = {0} }; + + if (!skb_flow_dissect(skb, &flow_keys_buf_dissector, &flow, 0)) + return -EINVAL; + switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) { case VIRTIO_NET_HDR_GSO_TCPV4: + if (flow.basic.n_proto != htons(ETH_P_IP) || + flow.basic.ip_proto != IPPROTO_TCP) + return -EINVAL; gso_type = SKB_GSO_TCPV4; break; case VIRTIO_NET_HDR_GSO_TCPV6: + if (flow.basic.n_proto != htons(ETH_P_IPV6) || + flow.basic.ip_proto != IPPROTO_TCP) + return -EINVAL; gso_type = SKB_GSO_TCPV6; break; case VIRTIO_NET_HDR_GSO_UDP: + if (flow.basic.ip_proto != IPPROTO_UDP) + return -EINVAL; gso_type = SKB_GSO_UDP; break; default: but I think we can block these packets without adding a flow dissector call for each untrusted packet (SKB_GSO_DODGY). > The alternative to harden the segmentation code itself with a gso_type > sanity check in every gso callback is more work and fragile. Actually, changes just to inet_gso_segment and ipv6_gso_segment will suffice: bool udpfrag = false, fixedid = false, gso_partial, encap; struct sk_buff *segs = ERR_PTR(-EINVAL); + unsigned int offset = 0, gso_type; const struct net_offload *ops; - unsigned int offset = 0; struct iphdr *iph; int proto, tot_len; int nhoff; @@ -1258,6 +1258,22 @@ struct sk_buff *inet_gso_segment(struct sk_buff *skb, skb_reset_transport_header(skb); + gso_type = skb_shinfo(skb)->gso_type; + if (gso_type & SKB_GSO_DODGY) { + switch (gso_type & (SKB_GSO_TCPV4 | SKB_GSO_UDP)) { + case SKB_GSO_TCPV4: + if (proto != IPPROTO_TCP) + goto out; + break; + case SKB_GSO_UDP: + if (proto != IPPROTO_UDP) + goto out; + break; + default: + goto out; + } + } and analogous for IPv6. For a real patch I would deduplicate this logic between them and move it to a separate helper function (in a header file, then).
WARNING: multiple messages have this Message-ID (diff)
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: syzbot <syzbot+fee64147a25aecd48055@syzkaller.appspotmail.com>, David Miller <davem@davemloft.net>, LKML <linux-kernel@vger.kernel.org>, linux-sctp@vger.kernel.org, Network Development <netdev@vger.kernel.org>, Neil Horman <nhorman@tuxdriver.com>, syzkaller-bugs@googlegroups.com, Vladislav Yasevich <vyasevich@gmail.com> Subject: Re: general protection fault in skb_segment Date: Tue, 02 Jan 2018 15:48:17 +0000 [thread overview] Message-ID: <CAF=yD-K9M1yps+SogVLSVgoi+ngKzKrwWH+xMr4-m+v-pqyXXQ@mail.gmail.com> (raw) In-Reply-To: <CAF=yD-+KwmB+fX+4A1RiCV6ZCDQbkGGSVu8YVMrAGxfVtG7ndQ@mail.gmail.com> > Good point. Packet sockets require CAP_NET_RAW, but this is also > taken for virtio, so we probably want more stringent entry tests here. That would be something like #include <linux/if_vlan.h> +#include <linux/skbuff.h> #include <uapi/linux/virtio_net.h> +#include <net/flow_dissector.h> static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, const struct virtio_net_hdr *hdr, @@ -12,14 +14,27 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, unsigned int gso_type = 0; if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) { + struct flow_keys flow = { .basic = {0} }; + + if (!skb_flow_dissect(skb, &flow_keys_buf_dissector, &flow, 0)) + return -EINVAL; + switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) { case VIRTIO_NET_HDR_GSO_TCPV4: + if (flow.basic.n_proto != htons(ETH_P_IP) || + flow.basic.ip_proto != IPPROTO_TCP) + return -EINVAL; gso_type = SKB_GSO_TCPV4; break; case VIRTIO_NET_HDR_GSO_TCPV6: + if (flow.basic.n_proto != htons(ETH_P_IPV6) || + flow.basic.ip_proto != IPPROTO_TCP) + return -EINVAL; gso_type = SKB_GSO_TCPV6; break; case VIRTIO_NET_HDR_GSO_UDP: + if (flow.basic.ip_proto != IPPROTO_UDP) + return -EINVAL; gso_type = SKB_GSO_UDP; break; default: but I think we can block these packets without adding a flow dissector call for each untrusted packet (SKB_GSO_DODGY). > The alternative to harden the segmentation code itself with a gso_type > sanity check in every gso callback is more work and fragile. Actually, changes just to inet_gso_segment and ipv6_gso_segment will suffice: bool udpfrag = false, fixedid = false, gso_partial, encap; struct sk_buff *segs = ERR_PTR(-EINVAL); + unsigned int offset = 0, gso_type; const struct net_offload *ops; - unsigned int offset = 0; struct iphdr *iph; int proto, tot_len; int nhoff; @@ -1258,6 +1258,22 @@ struct sk_buff *inet_gso_segment(struct sk_buff *skb, skb_reset_transport_header(skb); + gso_type = skb_shinfo(skb)->gso_type; + if (gso_type & SKB_GSO_DODGY) { + switch (gso_type & (SKB_GSO_TCPV4 | SKB_GSO_UDP)) { + case SKB_GSO_TCPV4: + if (proto != IPPROTO_TCP) + goto out; + break; + case SKB_GSO_UDP: + if (proto != IPPROTO_UDP) + goto out; + break; + default: + goto out; + } + } and analogous for IPv6. For a real patch I would deduplicate this logic between them and move it to a separate helper function (in a header file, then).
next prev parent reply other threads:[~2018-01-02 15:49 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-12-29 17:58 general protection fault in skb_segment syzbot 2017-12-30 7:42 ` Willem de Bruijn 2017-12-30 7:42 ` Willem de Bruijn 2017-12-30 11:54 ` Willem de Bruijn 2017-12-30 11:54 ` Willem de Bruijn 2017-12-30 13:51 ` Xin Long 2017-12-30 13:51 ` Xin Long 2017-12-31 0:52 ` Marcelo Ricardo Leitner 2017-12-31 0:52 ` Marcelo Ricardo Leitner 2017-12-31 2:25 ` Marcelo Ricardo Leitner 2017-12-31 2:25 ` Marcelo Ricardo Leitner 2017-12-31 8:41 ` Xin Long 2017-12-31 8:41 ` Xin Long 2017-12-31 9:17 ` Willem de Bruijn 2017-12-31 9:17 ` Willem de Bruijn 2017-12-31 9:52 ` Willem de Bruijn 2017-12-31 9:52 ` Willem de Bruijn 2018-01-02 15:48 ` Willem de Bruijn [this message] 2018-01-02 15:48 ` Willem de Bruijn 2018-01-02 17:23 ` Willem de Bruijn 2018-01-02 17:23 ` Willem de Bruijn 2018-01-16 20:32 ` Willem de Bruijn 2018-01-16 20:32 ` Willem de Bruijn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAF=yD-K9M1yps+SogVLSVgoi+ngKzKrwWH+xMr4-m+v-pqyXXQ@mail.gmail.com' \ --to=willemdebruijn.kernel@gmail.com \ --cc=davem@davemloft.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sctp@vger.kernel.org \ --cc=marcelo.leitner@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=nhorman@tuxdriver.com \ --cc=syzbot+fee64147a25aecd48055@syzkaller.appspotmail.com \ --cc=syzkaller-bugs@googlegroups.com \ --cc=vyasevich@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.