From patchwork Tue Oct 9 04:05:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dominique Martinet X-Patchwork-Id: 981004 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codewreck.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42TkDs26Jgz9s9G for ; Tue, 9 Oct 2018 15:06:21 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726491AbeJILVD (ORCPT ); Tue, 9 Oct 2018 07:21:03 -0400 Received: from nautica.notk.org ([91.121.71.147]:37482 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726427AbeJILVD (ORCPT ); Tue, 9 Oct 2018 07:21:03 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 647D6C009; Tue, 9 Oct 2018 06:06:06 +0200 (CEST) From: Dominique Martinet Cc: Dominique Martinet , v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, Eric Van Hensbergen , Latchesar Ionkov Subject: [PATCH 1/2] 9p/trans_fd: abort p9_read_work if req status changed Date: Tue, 9 Oct 2018 06:05:55 +0200 Message-Id: <1539057956-23741-1-git-send-email-asmadeus@codewreck.org> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <20181009020949.GA29622@nautica> References: <20181009020949.GA29622@nautica> To: unlisted-recipients:; (no To-header on input) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Dominique Martinet p9_read_work would try to handle an errored req even if it got put to error state by another thread between the lookup (that worked) and the time it had been fully read. The request itself is safe to use because we hold a ref to it from the lookup (for m->rreq, so it was safe to read into the request data buffer until this point), but the req_list has been deleted at the same time status changed, and client_cb already has been called as well, so we should not do either. Signed-off-by: Dominique Martinet Reported-by: syzbot+2222c34dc40b515f30dc@syzkaller.appspotmail.com Cc: Eric Van Hensbergen Cc: Latchesar Ionkov --- As written in reply to the bug report I'm not sure it's what syzbot complained about exactly, but it feels like a correct thing to do. The second patch is unrelated to the syzbot report, but something that occured to me while looking at this ; I'll take both into linux-next around the start of next week after getting some proper testing done unless remarks happen. (they pass basic tests already) net/9p/trans_fd.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c index 12559c474dde..a0317d459cde 100644 --- a/net/9p/trans_fd.c +++ b/net/9p/trans_fd.c @@ -292,7 +292,6 @@ static void p9_read_work(struct work_struct *work) __poll_t n; int err; struct p9_conn *m; - int status = REQ_STATUS_ERROR; m = container_of(work, struct p9_conn, rq); @@ -375,11 +374,17 @@ static void p9_read_work(struct work_struct *work) p9_debug(P9_DEBUG_TRANS, "got new packet\n"); m->rreq->rc.size = m->rc.offset; spin_lock(&m->client->lock); - if (m->rreq->status != REQ_STATUS_ERROR) - status = REQ_STATUS_RCVD; - list_del(&m->rreq->req_list); - /* update req->status while holding client->lock */ - p9_client_cb(m->client, m->rreq, status); + if (m->rreq->status == REQ_STATUS_SENT) { + list_del(&m->rreq->req_list); + p9_client_cb(m->client, m->rreq, REQ_STATUS_RCVD); + } else { + spin_unlock(&m->client->lock); + p9_debug(P9_DEBUG_ERROR, + "Request tag %d errored out while we were reading the reply\n", + m->rc.tag); + err = -EIO; + goto error; + } spin_unlock(&m->client->lock); m->rc.sdata = NULL; m->rc.offset = 0; From patchwork Tue Oct 9 04:05:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dominique Martinet X-Patchwork-Id: 981003 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codewreck.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42TkDk2VKNz9s9N for ; Tue, 9 Oct 2018 15:06:14 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726642AbeJILVE (ORCPT ); Tue, 9 Oct 2018 07:21:04 -0400 Received: from nautica.notk.org ([91.121.71.147]:37492 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726434AbeJILVD (ORCPT ); Tue, 9 Oct 2018 07:21:03 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id DE4C4C01A; Tue, 9 Oct 2018 06:06:07 +0200 (CEST) From: Dominique Martinet Cc: Dominique Martinet , v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Van Hensbergen , Latchesar Ionkov , Tomas Bortoli Subject: [PATCH 2/2] 9p/trans_fd: put worker reqs on destroy Date: Tue, 9 Oct 2018 06:05:56 +0200 Message-Id: <1539057956-23741-2-git-send-email-asmadeus@codewreck.org> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1539057956-23741-1-git-send-email-asmadeus@codewreck.org> References: <20181009020949.GA29622@nautica> <1539057956-23741-1-git-send-email-asmadeus@codewreck.org> To: unlisted-recipients:; (no To-header on input) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Dominique Martinet p9_read_work/p9_write_work might still hold references to a req after having been cancelled; make sure we put any of these to avoid potential request leak on disconnect. Fixes: 728356dedeff8 ("9p: Add refcount to p9_req_t") Signed-off-by: Dominique Martinet Cc: Eric Van Hensbergen Cc: Latchesar Ionkov Cc: Tomas Bortoli Reviewed-by: Tomas Bortoli --- Noticed we could leak a ref while looking at the syzbot report, this should be safe enough after the work has been cancelled... Probably. net/9p/trans_fd.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c index a0317d459cde..f868cf6fba79 100644 --- a/net/9p/trans_fd.c +++ b/net/9p/trans_fd.c @@ -876,7 +876,15 @@ static void p9_conn_destroy(struct p9_conn *m) p9_mux_poll_stop(m); cancel_work_sync(&m->rq); + if (m->rreq) { + p9_req_put(m->rreq); + m->rreq = NULL; + } cancel_work_sync(&m->wq); + if (m->wreq) { + p9_req_put(m->wreq); + m->wreq = NULL; + } p9_conn_cancel(m, -ECONNRESET);