From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8BEEAA055D for ; Mon, 15 Mar 2021 17:17:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 82ABE2426CC; Mon, 15 Mar 2021 17:17:25 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id 622914068C for ; Mon, 15 Mar 2021 17:17:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615825042; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Jss4IaoNaHtsZu/CoSrBwvEGKPxeUUmDlLFWAti47Ss=; b=YOG+SSST6daw52MVBn8zL0Bz2TTVx28wewiVdFCJS/HTDKpFl5n9T23+Bej0dXw/CDD51H ISOgl/FjAwtj9RRD1os6u6/YiqkWXnGVXr/uapZTfyExanceCCbnLhG9/8K+S37tIM/8im LA4trXb372o5qY4AEOcqoO7qwct1sq0= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-416-nzT_XxE8PWuKDgjgFYeunQ-1; Mon, 15 Mar 2021 12:17:20 -0400 X-MC-Unique: nzT_XxE8PWuKDgjgFYeunQ-1 Received: by mail-ua1-f71.google.com with SMTP id r9so5070785uan.9 for ; Mon, 15 Mar 2021 09:17:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jss4IaoNaHtsZu/CoSrBwvEGKPxeUUmDlLFWAti47Ss=; b=OskdphD1ZryHZq/ZZP6uByIV9LWDezH/atg8vyWxj1zMocQ6HNl6vzTvOB3kzu9pgs kIdoUtjbEIFWhUrD9W30NJb7u3qxE/arWzDeuhCqaChvSrpVVAmFzUKYRqRv4FSkCWgx dsHJBxgiQcBr20PjsGq+YoYTfrz0xQTMchnYDTaPmFKkJuzYg2/wCF2e47rt4JwYLw/Q usn/e2/5py3F+jB3U5eqZO6ytHsPtN54ypUZ6La6IqHpYAQ7PRvs+xnqKO5/UIhpa8hg EHcWUP5cG4suHs7XzC9Boq1tCS94Q/KWN2eLttz9Grk84+Ou2u61w8NubDoxQ7owPIrN Jh9A== X-Gm-Message-State: AOAM530bKS/Bz//J/HnznYew4kcFAwoY0HKKwRYkdDeIW39D7ezTKd+i Fh14ge4T0oS+76SbY8ICke1KV5J/c52JvwheoVegZWNOTJAlUAP4ActWWYR05dVoeHXlHUIAoEn lQWea6xf3Mk5Lt0WWXegYsbw= X-Received: by 2002:a9f:2722:: with SMTP id a31mr5377865uaa.86.1615825039878; Mon, 15 Mar 2021 09:17:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygb59GnccbUzCvgroDDlA9Z50sFCh6jquv82DpWtbABbv5jb/nsLV6Noq/djd2nc93SNLaC0WlCSrPDFpshz4= X-Received: by 2002:a9f:2722:: with SMTP id a31mr5377848uaa.86.1615825039605; Mon, 15 Mar 2021 09:17:19 -0700 (PDT) MIME-Version: 1.0 References: <20210311063827.55394-1-xiao.w.wang@intel.com> <20210315153255.113442-1-xiao.w.wang@intel.com> In-Reply-To: <20210315153255.113442-1-xiao.w.wang@intel.com> From: David Marchand Date: Mon, 15 Mar 2021 17:17:08 +0100 Message-ID: To: Xiao Wang Cc: "Xia, Chenbo" , Maxime Coquelin , Marvin Liu , dev , "Ananyev, Konstantin" , dpdk stable Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-stable] [PATCH v2] vhost: add header check in dequeue offload X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Mon, Mar 15, 2021 at 4:52 PM Xiao Wang wrote: > > When parsing the virtio net header and packet header for dequeue offload, > we need to perform sanity check on the packet header to ensure: > - No out-of-boundary memory access. > - The packet header and virtio_net header are valid and aligned. > > Fixes: d0cf91303d73 ("vhost: add Tx offload capabilities") > Cc: stable@dpdk.org > > Signed-off-by: Xiao Wang > --- > v2: > Allow empty L4 payload for cksum offload. > --- > lib/librte_vhost/virtio_net.c | 49 +++++++++++++++++++++++++++++++++++++------ > 1 file changed, 43 insertions(+), 6 deletions(-) > > diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c > index 583bf379c6..53a8ff2898 100644 > --- a/lib/librte_vhost/virtio_net.c > +++ b/lib/librte_vhost/virtio_net.c > @@ -1821,44 +1821,64 @@ virtio_net_with_host_offload(struct virtio_net *dev) > return false; > } > > -static void > -parse_ethernet(struct rte_mbuf *m, uint16_t *l4_proto, void **l4_hdr) > +static int > +parse_ethernet(struct rte_mbuf *m, uint16_t *l4_proto, void **l4_hdr, > + uint16_t *len) > { > struct rte_ipv4_hdr *ipv4_hdr; > struct rte_ipv6_hdr *ipv6_hdr; > void *l3_hdr = NULL; > struct rte_ether_hdr *eth_hdr; > uint16_t ethertype; > + uint16_t data_len = m->data_len; > > eth_hdr = rte_pktmbuf_mtod(m, struct rte_ether_hdr *); > > + if (data_len <= sizeof(struct rte_ether_hdr)) > + return -EINVAL; On principle, the check should happen before calling rte_pktmbuf_mtod, like what rte_pktmbuf_read does. Looking at the rest of the patch, does this helper function only handle mono segment mbufs? My reading of copy_desc_to_mbuf() was that it could generate multi segments mbufs... [snip] > case RTE_ETHER_TYPE_IPV4: > + if (data_len <= sizeof(struct rte_ipv4_hdr)) > + return -EINVAL; > ipv4_hdr = l3_hdr; > *l4_proto = ipv4_hdr->next_proto_id; > m->l3_len = rte_ipv4_hdr_len(ipv4_hdr); > + if (data_len <= m->l3_len) { > + m->l3_len = 0; > + return -EINVAL; > + } ... so here, comparing l3 length to only the first segment length (data_len) would be invalid. If this helper must deal with multi segments, why not use rte_pktmbuf_read? This function returns access to mbuf data after checking offset and length are contiguous, else copy the needed data in a passed buffer. > *l4_hdr = (char *)l3_hdr + m->l3_len; > m->ol_flags |= PKT_TX_IPV4; > + data_len -= m->l3_len; > break; -- David Marchand