Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1591298imm; Thu, 12 Jul 2018 04:44:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcbMXNOx69Cuy3LJYpj5dm/ah1mkPBcr+Ih+wte1uJTY3V0nqj5r6oJ0D2yIJq5e81Mg700 X-Received: by 2002:a65:5907:: with SMTP id f7-v6mr1760548pgu.83.1531395852096; Thu, 12 Jul 2018 04:44:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531395852; cv=none; d=google.com; s=arc-20160816; b=saydYlAQsZ5A/TimYx3u9OTSUgrGniuWaN/bRevfKBupju3jl14I22yJYj4kbEc2Bz BzX3e1eA8E6vNOR2w4ob7dmdRLq9cfa5bc/AXqMa43usZLds4mii2HfLp8ooF9+hOnkA xNXKBfGjG11/RdeeygXqT8cb/g0pv6Y0dFke7DFc3Nc4NmFrhPkzPIUgUhkyWlDwTrpA XzDpG1+7WIWuzPRBgC7GfPzxICaFYpEO7Tu7pLA2PcIseLVILpFETQj0KCsNXlHSigYW QJ7Fn9XOZd5nNhK0WrU7cglD2JBuihfzENdOqIoBMP3q+7XBM0gVDzuqYKA0p6CcyoFN zWZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=MngY7gamF5sPUrixJ7W1xeC62UUJUK7ar/q0p51FlIs=; b=NBIp2JnQOTZJroU9WRt/hVlBA3BduO9lCeVzRfDdM52I94w+2Tb5pLPf4pUdg9+h14 v5D86jio/fo5PPNuwx/vNTUtg7Myd6gUM3sh9c7f8nIDG7ApndK1xzqGzYbrwIK03iVB xLoLnWiyAElxukD0Mzizh0Z9x+CNHlIz74+mSz5M8UQKK1YTkyB8FW6+zxT5Cw5lGyxW gbs8dVRlv0XUCUSfX5fk0HX1b23x/dKk3n/HMKLfyk4fub/LBcBkaUQ7Guz7sZsT2nyQ eXn7gx3xmv5X7G1jtsNn2Wzr+GttIfxlscFNmNRL/+zzw/jI3qbTtcpIxbub2/fkOZ1x 84Rg== 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 bh7-v6si20933148plb.367.2018.07.12.04.43.57; Thu, 12 Jul 2018 04:44:12 -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 S1726961AbeGLLwb (ORCPT + 99 others); Thu, 12 Jul 2018 07:52:31 -0400 Received: from nautica.notk.org ([91.121.71.147]:56412 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726575AbeGLLwb (ORCPT ); Thu, 12 Jul 2018 07:52:31 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id F23D5C009; Thu, 12 Jul 2018 13:43:19 +0200 (CEST) Date: Thu, 12 Jul 2018 13:43:04 +0200 From: Dominique Martinet To: Tomas Bortoli Cc: ericvh@gmail.com, rminnich@sandia.gov, lucho@ionkov.net, viro@ZenIV.linux.org.uk, davem@davemloft.net, v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller@googlegroups.com Subject: Re: [V9fs-developer] [PATCH] p9_parse_header() validate PDU length Message-ID: <20180712114304.GB17774@nautica> References: <20180712110211.25535-1-tomasbortoli@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180712110211.25535-1-tomasbortoli@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tomas Bortoli wrote on Thu, Jul 12, 2018: > This patch adds checks to the p9_parse_header() function to > verify that the length found within the header coincides with the actual > length of the PDU. Furthermore, it checks that the length stays within the > acceptable range. To do this the patch brings the actual length of the PDU > from the different transport layers (rdma and virtio). For TCP (trans_fd.c) > the length is not know before, so we get it from the header but we check it > anyway that it's within the valid range. Just a note on transports here, I totally had forgotten about trans_xen when we discussed this earlier as it is fairly new, but it looks like it sets the length in the fcall properly so it should work without any change. I however cannot test trans=xen, so if someone could either point me to how to set that up (I couldn't find any decent documentation) or do some very basic tests that would be great. > Signed-off-by: Tomas Bortoli > Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com Looks good to me, as the rdma/virtio part come from my suggestion: Signed-off-by: Dominique Martinet > diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c > index 3d414acb7015..002badbcc9c0 100644 > --- a/net/9p/trans_rdma.c > +++ b/net/9p/trans_rdma.c > @@ -319,7 +319,7 @@ recv_done(struct ib_cq *cq, struct ib_wc *wc) > > if (wc->status != IB_WC_SUCCESS) > goto err_out; > - > + c->rc->size = wc->byte_len; (nitpick, I'd keep the empty line here. If you don't mind I'll add it back in my tree; this doesn't warrant a v2) -- Dominique Martinet