From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaxM8-00045s-Lb for qemu-devel@nongnu.org; Tue, 01 Mar 2016 22:21:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaxM4-0000FZ-Ke for qemu-devel@nongnu.org; Tue, 01 Mar 2016 22:21:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaxM4-0000FU-Eg for qemu-devel@nongnu.org; Tue, 01 Mar 2016 22:21:40 -0500 References: <1456243707-29345-1-git-send-email-ppandit@redhat.com> <1456243707-29345-2-git-send-email-ppandit@redhat.com> <56CFEC59.8040503@redhat.com> From: Jason Wang Message-ID: <56D65C36.6030702@redhat.com> Date: Wed, 2 Mar 2016 11:21:26 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/2] net: check packet payload length List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: P J P Cc: Markus Armbruster , Qemu Developers , Liu Ling On 03/01/2016 02:48 PM, P J P wrote: > Hello Jason, > > +-- On Fri, 26 Feb 2016, Jason Wang wrote --+ > | Should we count mac header here? Did "plen + hlen >= length" imply "14 + > | hlen + csum_offset + 1" < length? > | > | Looks not. Consider a TCP packet can report evil plen (e.g 20) but just > | have 10 bytes payload in fact. In this case: > | > | hlen = 20, plen = 20, csum_offset = 16, length = 44 which can pass all > | the above tests, but 14 + hlen + csum_offset = 50 which is greater than > | length. > > Ummn, not sure. hlen + plen = total length(IP + TCP/UDP), 20+20 != 44. > 'length' is also used to read and allocate requisite buffers in other parts > from where net_checksum_calculate() is called, > > === > etsec->tx_buffer = g_realloc(etsec->tx_buffer, > etsec->tx_buffer_len + bd->length); > ... > /* Update buffer length */ > etsec->tx_buffer_len += bd->length; > > process_tx_fcb(etsec); > -> net_checksum_calculate(etsec->tx_buffer + 8, > etsec->tx_buffer_len - 8); > > OR > > memcpy(tmpbuf, page + txreq.offset, txreq.size); > net_checksum_calculate(tmpbuf, txreq.size); > === > > - With 'length < 14 + 20', we ensure that L2 & L3 headers are complete. How about L4, since we will calculate L4 checksum I believe? And it looks like the following check: plen + hlen >= length only count L3 header plus payload? > 44 - 34 = 10, TCP/UDP header is incomplete. > > I think 'plen=20 != 10' hints at an error in other parts of the code? Well, the point is. If we want depend on callers to do all the checks, we need fix all the callers. Otherwise, we need to do all the check in net_checksum_calculate() itself (E.g to handle all kinds of evil packets). > Also if > data buffer has more space than actual data, OOB access may not occur. > > -- > Prasad J Pandit / Red Hat Product Security Team > 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F >