Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1190382imm; Mon, 9 Jul 2018 19:39:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdZjz7vIsJViCMWzBKTVVEJqx3fqH0uS8NfXfIKe4mwOSNp5m+DEjjz5D6CeqRXMhmbZ0X6 X-Received: by 2002:a63:c60:: with SMTP id 32-v6mr21138672pgm.155.1531190352877; Mon, 09 Jul 2018 19:39:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531190352; cv=none; d=google.com; s=arc-20160816; b=Y9J2PE2OKb75dSy0FRAAodYGfmq3SQETBD/+7zN6Fx6TDDB3A5KglknoDG7TTIGnSc AscDX/2JkxBHzObyHf2PEzUYqm4rmwqBfI6dYIFzD+7Yhzeq14ifi54uy0VV0kqsgWwc nQmGa24qHzkR0Dgqlg09L/Cdoc+g/sWAOOGLntThvektbLBYGMGkFB3VXA/Q1Eh4KBAa t2sXdLZiHiBfvviCofZHNgVJQXfCv+6NX6U06rX2u8Q8cGz+bXSmPMe8OpE59P41ky7U A0DTN5KRJxlD0VlhhT5PGQnYjbvRMsyJKyE6pem/Ytb1fsY3lu7rExBnRB1BJwuYySci WZMQ== 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=Xpd9glcWfiUQN+YxejZ2JsA/qqpeje5/YaQk0E7zWPM=; b=H4j06uhPf+scp8fSgp3gbqieW7ovk2HL4exETd6qwEbZR83ThYzKlzRjnZoywoIRuX FRzGCVrNDi85EPSOKM3xfqaH4yEwGp1LujXW4VlHQf5KwJ3ImpS3UlViiHOwwhof+ZJ6 7l7Lo+Fd9YyAoBeGRMJMAxmMe9rbHaF7tKKWGHKACCde1o3uLFCYW0qwlr1ZGxFih/Hk 9F5iuJfd0tvlYniJJb9pDh8P+/38E2xO4aE/SBRDEN7JbImRF90XuBDodwlK0EiojGX9 FXaXT6WrcDDd/ncji+hdbxhFd9AjsKNxgm1228gDqhbSvUAXXBc6h5miv2xaRGQzQKI5 ArKw== 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 k188-v6si15339978pgc.321.2018.07.09.19.38.57; Mon, 09 Jul 2018 19:39: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 S933096AbeGJCiM (ORCPT + 99 others); Mon, 9 Jul 2018 22:38:12 -0400 Received: from nautica.notk.org ([91.121.71.147]:49922 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932797AbeGJCiH (ORCPT ); Mon, 9 Jul 2018 22:38:07 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 8C0E8C009; Tue, 10 Jul 2018 04:28:34 +0200 (CEST) Date: Tue, 10 Jul 2018 04:28:19 +0200 From: Dominique Martinet To: Tomas Bortoli Cc: ericvh@gmail.com, rminnich@sandia.gov, lucho@ionkov.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller@googlegroups.com, v9fs-developer@lists.sourceforge.net, davem@davemloft.net, Al Viro Subject: Re: [V9fs-developer] [PATCH] p9_check_errors() validate PDU length Message-ID: <20180710022819.GA19285@nautica> References: <20180709224323.20597-1-tomasbortoli@gmail.com> <20180709235403.GB19917@nautica> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180709235403.GB19917@nautica> 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 Tue, Jul 10, 2018: > As suggested by Dominique: > https://lkml.org/lkml/2018/7/9/688 > Such check is not enough as it will prevent to read more than how it has > been allocated but it won't prevent to read more than how it has been read > So this patch will require some more changes to prevent bad sizes. Sorry, I'm the one who suggested to put a note after the commit message and I didn't see it. Let's get the proper fix right away, it's not much further. > Also, they really need to check against the actual read size, not just > capacity. > For virtio/rdma, something like this ought to fix pdu->size, then > p9_parse_header can just never overwrite it (untested but it's useless > on its own, I'll test the full patch with the parse header change) I actually took the time to test a bit; I had only suggested something for virtio/rdma because I had assumed trans_fd (the socket transport actually used by syzbot) was setting the length in the fcall, but I read that code too fast this morning and it is not (it only sets the size in its private struct) Something like that ought to work for trans_fd: diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c index 588bf88c3305..9f3ce370c685 100644 --- a/net/9p/trans_fd.c +++ b/net/9p/trans_fd.c @@ -369,6 +370,7 @@ static void p9_read_work(struct work_struct *work) */ if ((m->req) && (m->rc.offset == m->rc.capacity)) { p9_debug(P9_DEBUG_TRANS, "got new packet\n"); + m->req->rc->size = m->rc.offset; spin_lock(&m->client->lock); if (m->req->status != REQ_STATUS_ERROR) status = REQ_STATUS_RCVD; --- This however gets more complicated once you start factoring in that change I suggested about p9_parse_header not setting size (and checking size) because trans_fd relies on it; so I'm not sure how we should proceed. Do you have a working 9p tcp server to test changes are valid, or are you only working off the syzbot reproducer? In the first place, are you willing to take the time to do that bigger fix? At this point I can either help you get a working setup and let you do the rest, or just finish the bigger patch myself and add you as whatever tag you feel comfortable with (persumably Signed-off-by) Thanks again for starting this, -- Dominique Martinet | Asmadeus