Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 12 Aug 2021 10:06:46 +0530
From:   Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
To:     davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
        willemb@google.com, xie.he.0141@gmail.com, gustavoars@kernel.org,
        wanghai38@huawei.com, tannerlove@google.com, eyal.birger@gmail.com,
        rsanger@wand.net.nz, jiapeng.chong@linux.alibaba.com
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Can a valid vnet header have both csum_start and csum_offset 0?
Message-ID: <YRSlXr2bsFfZOBgw@fedora>
References: <YRLONiYsdqKLeja3@fedora>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YRLONiYsdqKLeja3@fedora>
Precedence: bulk

On Wed, Aug 11, 2021 at 12:36:38AM +0530, Shreyansh Chouhan wrote:
> Hi,
> 
> When parsing the vnet header in __packet_snd_vnet_parse[1], we do not
> check for if the values of csum_start and csum_offset given in the
> header are both 0.
> 
> Having both these values 0, however, causes a crash[2] further down the
> gre xmit code path. In the function ipgre_xmit, we pull the ip header
> and gre header from skb->data, this results in an invalid
> skb->csum_start which was calculated from the vnet header. The
> skb->csum_start offset in this case turns out to be lower than
> skb->transport_header. This causes us to pass a negative number as an
> argument to csum_partial[3] and eventually to do_csum[4], which then causes
> a kernel oops in the while loop.
> 
> I do not understand what should the correct behavior be in this
> scenario, should we consider this vnet header as invalid?

Something like the following diff:

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 57a1971f29e5..65bff1c8f75c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2479,13 +2479,17 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
 
 static int __packet_snd_vnet_parse(struct virtio_net_hdr *vnet_hdr, size_t len)
 {
+	__u16 csum_start = __virtio16_to_cpu(vio_le(), vnet_hdr->csum_start);
+	__u16 csum_offset = __virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset);
+	__u16 hdr_len = __virtio16_to_cpu(vio_le(), vnet_hdr->hdr_len);
+
+	if (csum_start + csum_offset == 0)
+		return -EINVAL;
+
 	if ((vnet_hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) &&
-	    (__virtio16_to_cpu(vio_le(), vnet_hdr->csum_start) +
-	     __virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset) + 2 >
-	      __virtio16_to_cpu(vio_le(), vnet_hdr->hdr_len)))
+	    csum_start + csum_offset + 2 > hdr_len)
 		vnet_hdr->hdr_len = __cpu_to_virtio16(vio_le(),
-			 __virtio16_to_cpu(vio_le(), vnet_hdr->csum_start) +
-			__virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset) + 2);
+				csum_start + csum_offset + 2);
 
 	if (__virtio16_to_cpu(vio_le(), vnet_hdr->hdr_len) > len)
 		return -EINVAL;

> Or should we rather accomodate for both csum_start
> and csum_offset values to be 0 in ipgre_xmit?
> 
> Regards,
> Shreyansh Chouhan
> 
> --
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/packet/af_packet.c#n2480
> [2] https://syzkaller.appspot.com/bug?id=c391f74aac26dd8311c45743ae618f9d5e38b674
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/skbuff.h#n4662
> [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/lib/csum-partial_64.c#n35