From: "Michael S. Tsirkin" <mst@redhat.com>
To: Balazs Nemeth <bnemeth@redhat.com>
Cc: willemb@google.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, davem@davemloft.net
Subject: Re: [PATCH v2 1/2] net: check if protocol extracted by virtio_net_hdr_set_proto is correct
Date: Tue, 9 Mar 2021 06:26:06 -0500 [thread overview]
Message-ID: <20210309062116-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <8f2cb8f8614d86bba02df73c1a0665179583f1c3.1615199056.git.bnemeth@redhat.com>
On Mon, Mar 08, 2021 at 11:31:25AM +0100, Balazs Nemeth wrote:
> For gso packets, virtio_net_hdr_set_proto sets the protocol (if it isn't
> set) based on the type in the virtio net hdr, but the skb could contain
> anything since it could come from packet_snd through a raw socket. If
> there is a mismatch between what virtio_net_hdr_set_proto sets and
> the actual protocol, then the skb could be handled incorrectly later
> on.
>
> An example where this poses an issue is with the subsequent call to
> skb_flow_dissect_flow_keys_basic which relies on skb->protocol being set
> correctly. A specially crafted packet could fool
> skb_flow_dissect_flow_keys_basic preventing EINVAL to be returned.
>
> Avoid blindly trusting the information provided by the virtio net header
> by checking that the protocol in the packet actually matches the
> protocol set by virtio_net_hdr_set_proto. Note that since the protocol
> is only checked if skb->dev implements header_ops->parse_protocol,
> packets from devices without the implementation are not checked at this
> stage.
>
> Fixes: 9274124f023b ("net: stricter validation of untrusted gso packets")
> Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
> ---
> include/linux/virtio_net.h | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index e8a924eeea3d..6c478eee0452 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -79,8 +79,14 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> if (gso_type && skb->network_header) {
> struct flow_keys_basic keys;
>
> - if (!skb->protocol)
> + if (!skb->protocol) {
> + const struct ethhdr *eth = skb_eth_hdr(skb);
> + __be16 etype = dev_parse_header_protocol(skb);
> +
> virtio_net_hdr_set_proto(skb, hdr);
> + if (etype && etype != skb->protocol)
> + return -EINVAL;
> + }
Well the protocol in the header is an attempt at an optimization to
remove need to parse the packet ... any data on whether this
affecs performance?
> retry:
> if (!skb_flow_dissect_flow_keys_basic(NULL, skb, &keys,
> NULL, 0, 0, 0,
> --
> 2.29.2
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Balazs Nemeth <bnemeth@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
jasowang@redhat.com, davem@davemloft.net, willemb@google.com,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v2 1/2] net: check if protocol extracted by virtio_net_hdr_set_proto is correct
Date: Tue, 9 Mar 2021 06:26:06 -0500 [thread overview]
Message-ID: <20210309062116-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <8f2cb8f8614d86bba02df73c1a0665179583f1c3.1615199056.git.bnemeth@redhat.com>
On Mon, Mar 08, 2021 at 11:31:25AM +0100, Balazs Nemeth wrote:
> For gso packets, virtio_net_hdr_set_proto sets the protocol (if it isn't
> set) based on the type in the virtio net hdr, but the skb could contain
> anything since it could come from packet_snd through a raw socket. If
> there is a mismatch between what virtio_net_hdr_set_proto sets and
> the actual protocol, then the skb could be handled incorrectly later
> on.
>
> An example where this poses an issue is with the subsequent call to
> skb_flow_dissect_flow_keys_basic which relies on skb->protocol being set
> correctly. A specially crafted packet could fool
> skb_flow_dissect_flow_keys_basic preventing EINVAL to be returned.
>
> Avoid blindly trusting the information provided by the virtio net header
> by checking that the protocol in the packet actually matches the
> protocol set by virtio_net_hdr_set_proto. Note that since the protocol
> is only checked if skb->dev implements header_ops->parse_protocol,
> packets from devices without the implementation are not checked at this
> stage.
>
> Fixes: 9274124f023b ("net: stricter validation of untrusted gso packets")
> Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
> ---
> include/linux/virtio_net.h | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index e8a924eeea3d..6c478eee0452 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -79,8 +79,14 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> if (gso_type && skb->network_header) {
> struct flow_keys_basic keys;
>
> - if (!skb->protocol)
> + if (!skb->protocol) {
> + const struct ethhdr *eth = skb_eth_hdr(skb);
> + __be16 etype = dev_parse_header_protocol(skb);
> +
> virtio_net_hdr_set_proto(skb, hdr);
> + if (etype && etype != skb->protocol)
> + return -EINVAL;
> + }
Well the protocol in the header is an attempt at an optimization to
remove need to parse the packet ... any data on whether this
affecs performance?
> retry:
> if (!skb_flow_dissect_flow_keys_basic(NULL, skb, &keys,
> NULL, 0, 0, 0,
> --
> 2.29.2
next prev parent reply other threads:[~2021-03-09 11:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 10:31 [PATCH v2 0/2] net: prevent infinite loop caused by incorrect proto from virtio_net_hdr_set_proto Balazs Nemeth
2021-03-08 10:31 ` [PATCH v2 1/2] net: check if protocol extracted by virtio_net_hdr_set_proto is correct Balazs Nemeth
2021-03-08 16:01 ` Willem de Bruijn
2021-03-08 16:01 ` Willem de Bruijn
2021-03-09 11:26 ` Michael S. Tsirkin [this message]
2021-03-09 11:26 ` Michael S. Tsirkin
2021-03-09 14:02 ` Willem de Bruijn
2021-03-09 14:02 ` Willem de Bruijn
2021-03-08 10:31 ` [PATCH v2 2/2] net: avoid infinite loop in mpls_gso_segment when mpls_hlen == 0 Balazs Nemeth
2021-03-08 16:07 ` Willem de Bruijn
2021-03-08 16:07 ` Willem de Bruijn
2021-03-08 16:17 ` David Ahern
2021-03-08 16:17 ` David Ahern
2021-03-08 16:26 ` Balazs Nemeth
2021-03-08 16:42 ` David Ahern
2021-03-08 16:42 ` David Ahern
2021-03-08 18:11 ` Willem de Bruijn
2021-03-08 18:11 ` 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=20210309062116-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=bnemeth@redhat.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=willemb@google.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: link
Be 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.