linux-kernel - Re: Can a valid vnet header have both csum_start and csum

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: <YRSlXr2bsFfZOBgw@fedora>
Date:   Thu, 12 Aug 2021 10:06:46 +0530
From:   Shreyansh Chouhan <chouhan.shreyansh630@...il.com>
To:     davem@...emloft.net, kuba@...nel.org, edumazet@...gle.com,
        willemb@...gle.com, xie.he.0141@...il.com, gustavoars@...nel.org,
        wanghai38@...wei.com, tannerlove@...gle.com, eyal.birger@...il.com,
        rsanger@...d.net.nz, jiapeng.chong@...ux.alibaba.com
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Can a valid vnet header have both csum_start and csum_offset 0?

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