Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1568986imm; Tue, 10 Jul 2018 04:19:10 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe7HGW6StVCUAlCOFj73woFUo+YO4YohcIWHcKbdabx3l3KsEfCvgq8PS+y4p2RueIGQ0qp X-Received: by 2002:a63:4763:: with SMTP id w35-v6mr22044022pgk.140.1531221550043; Tue, 10 Jul 2018 04:19:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531221550; cv=none; d=google.com; s=arc-20160816; b=0EPPXaqsmR9TKfB3befiaOwdcIE7DiNoQUGHF5wZppNEw7EMk5uaeRpTjnI+23JXg4 hUgylprR7pJm1QQGhQgcmew1G77dy88mDgd8ZoMadMyNwJIui8ciyjoZxGiDcOTeXifh CdCwq+3r1f2mgTUOyIdta2EY19LHBUUixBUURoSvPIho3MWtatqoM/XzCsqa3+2/D/lW JKzTZIBcoXR2EGIaPTvrULXLTqs55ELK/Gvgmsf8kvKB/LR7xH/iHEQNEk0p4QFWicJI eNtiGKAvoqWkCD4LJWMWyOuKCieSpxxz+PHElmom79DIWNpZEvY5FlQW/hoQ8eQV8IzX 8iBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=AGI1gfFxS5kdEzDsVynfqxSVcqpkbNEKOxG68tGZrfk=; b=dgTdPfRS4CYTO9yM/vVQHdtRUpqxKKzwkRK0b5RgUkB2eryOdHDsKjbnP+K0AnfKE8 k/eorYZ+HPBIlrDmjZAOLOj85ELVen/qF+xUM9AUFI4xYdEz/C90Kgc/Bi/TkNqeySXi hHEP5+lRUXrnWmBQ4jOs8/zQTupVE0LexI4XIzO2hykeE5fJzFtVAGlMl0hzw/zfHKZt YbTlnaL2YYceR1DKv5C9z8lIwpMPQnxdtkvv3QHGxRrQduL1+1QWd1VeZe35yuRwg5rx OiVzsevWNFn2lvmE29YiGc+O7oS3GzZrDvN8An1k1QrQd0Ttm0o18CDNj3G1jiUe3n6w hsYw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w27-v6si16352534pgk.664.2018.07.10.04.18.38; Tue, 10 Jul 2018 04:19:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933255AbeGJLRQ (ORCPT + 99 others); Tue, 10 Jul 2018 07:17:16 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:9216 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751527AbeGJLRP (ORCPT ); Tue, 10 Jul 2018 07:17:15 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 1F6B36D79B1DA; Tue, 10 Jul 2018 19:16:59 +0800 (CST) Received: from [10.177.253.249] (10.177.253.249) by smtp.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.382.0; Tue, 10 Jul 2018 19:16:59 +0800 Subject: Re: [V9fs-developer] [PATCH] Integer underflow in pdu_read() To: Tomas Bortoli , , , References: <20180709192651.28095-1-tomasbortoli@gmail.com> CC: , , , , From: piaojun Message-ID: <5B44959E.2000108@huawei.com> Date: Tue, 10 Jul 2018 19:16:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20180709192651.28095-1-tomasbortoli@gmail.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.253.249] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tomas, I found some other subtraction between pdu->size and pdu->offset such as: p9pdu_vreadf() --min_t(uint32_t, *count, pdu->size - pdu->offset); p9_check_zc_errors() --len = req->rc->size - req->rc->offset; I wonder if there are underflow risks? Thanks, Jun On 2018/7/10 3:26, Tomas Bortoli wrote: > The pdu_read() function suffers from an integer underflow. > When pdu->offset is greater than pdu->size, the length calculation will have > a wrong result, resulting in an out-of-bound read. > This patch modifies also pdu_write() in the same way to prevent the same > issue from happening there and for consistency. > > Signed-off-by: Tomas Bortoli > Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com > --- > net/9p/protocol.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/net/9p/protocol.c b/net/9p/protocol.c > index 931ea00c4fed..f1e2425f920b 100644 > --- a/net/9p/protocol.c > +++ b/net/9p/protocol.c > @@ -55,16 +55,20 @@ EXPORT_SYMBOL(p9stat_free); > > size_t pdu_read(struct p9_fcall *pdu, void *data, size_t size) > { > - size_t len = min(pdu->size - pdu->offset, size); > - memcpy(data, &pdu->sdata[pdu->offset], len); > + size_t len = pdu->offset > pdu->size ? 0 : > + min(pdu->size - pdu->offset, size); > + if (len != 0) > + memcpy(data, &pdu->sdata[pdu->offset], len); > pdu->offset += len; > return size - len; > } > > static size_t pdu_write(struct p9_fcall *pdu, const void *data, size_t size) > { > - size_t len = min(pdu->capacity - pdu->size, size); > - memcpy(&pdu->sdata[pdu->size], data, len); > + size_t len = pdu->size > pdu->capacity ? 0 : > + min(pdu->capacity - pdu->size, size); > + if (len != 0) > + memcpy(&pdu->sdata[pdu->size], data, len); > pdu->size += len; > return size - len; > } >