Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp807753iog; Thu, 30 Jun 2022 10:28:45 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uRW2jxS/WkOvHMUqwpmxSRWFjMp9wS7K61NxpNNyMP7cCS7SVGhRseYjXkWvnVxszbaZpQ X-Received: by 2002:a17:906:8444:b0:72a:7dda:5d71 with SMTP id e4-20020a170906844400b0072a7dda5d71mr971001ejy.94.1656610125736; Thu, 30 Jun 2022 10:28:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656610125; cv=none; d=google.com; s=arc-20160816; b=i3qLIKExf1fdMPqSZLehyrMHZdt82mp/IzizJ2A1Pu1UcrKqZERw46OIp7N4FwavA/ jfzj6QSIfiGqwBJR+Xv2SxDBwV45eAUNt9HOepj+ICO8Un/3HG+ei1dRQWvvb/Hpb2S9 cHDq3MU01hQIHK3xs6LybP4YX5yygBK5yllUggTLFzjBA0amnCRHIuPRNtogtW0KcgIG U/urOpxGQxZ13fS5PMyxKfp9w/M2oyYvvVsD7JOQ+o/jVzpu5pdfPkHe7OmrUJUgx97s c5F6d6w647k7x8K9uhGrrX9cLbkET6Hdo637VYDSA1xkFXm6GtNvl9rlgYNW2jjhwyXN O0Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:message-id:date:cc:to:from:subject; bh=JRYrjXUCgTmhAky2F5i0fbRQflBPvAM4oXPbN6PTkFQ=; b=JHKsMcK21lDJXARlJb/OFhcW8J1Ym/jQp3L9LnyTEI8jFaDhwpt/LrVQSD6TZayxLX I1MDn5wfPobkh2XapnBUpWMzyOb5t62ZV7gpyDjiQkFP03j8iu3vIETEQZQAPjvS3wGR +1rUK9VbHVRYcfug8TZ5ezm3B25acf7FH+jfdE048qy/W2tdNotcIBXI5Vpih6c1cuH9 SC28crzBy08ehO1HGl7W0TGT9t0zLXkEqzwemD+6AiSa3GHmOH90ZSictJLbs8nOP9Pq tBAzp1n0DOxAE6P40D0PE/T5RX9q6QTN3+M/3LO4QcMImKMo2ffebzgD+ou1gpS/bhv6 qxaA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id zb13-20020a17090687cd00b00726cbdd4692si3889328ejb.86.2022.06.30.10.28.07; Thu, 30 Jun 2022 10:28:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235650AbiF3RY0 (ORCPT + 99 others); Thu, 30 Jun 2022 13:24:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235207AbiF3RYZ (ORCPT ); Thu, 30 Jun 2022 13:24:25 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4553434641 for ; Thu, 30 Jun 2022 10:24:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E7B52B82CC1 for ; Thu, 30 Jun 2022 17:24:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F2A1C34115; Thu, 30 Jun 2022 17:24:21 +0000 (UTC) Subject: [PATCH v1] SUNRPC: Fix READ_PLUS crasher From: Chuck Lever To: linux-nfs@vger.kernel.org Cc: anna.schumaker@netapp.com, bfields@fieldses.org, zlang@redhat.com Date: Thu, 30 Jun 2022 13:24:20 -0400 Message-ID: <165660978413.2453.15153844664543877314.stgit@klimt.1015granger.net> User-Agent: StGit/1.5.dev3+g9561319 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Looks like there are still cases when "space_left - frag1bytes" can legitimately exceed PAGE_SIZE. Ensure that xdr->end always remains within the current encode buffer. Reported-by: Bruce Fields Reported-by: Zorro Lang Link: https://bugzilla.kernel.org/show_bug.cgi?id=216151 Fixes: 6c254bf3b637 ("SUNRPC: Fix the calculation of xdr->end in xdr_get_next_encode_buffer()") Signed-off-by: Chuck Lever --- net/sunrpc/xdr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Hi- I had a few minutes yesterday afternoon to look into this one. The following one-liner seems to address the issue and passes my smoke tests with NFSv4.1/TCP and NFSv3/RDMA. Any thoughts? diff --git a/net/sunrpc/xdr.c b/net/sunrpc/xdr.c index f87a2d8f23a7..916659be2774 100644 --- a/net/sunrpc/xdr.c +++ b/net/sunrpc/xdr.c @@ -987,7 +987,7 @@ static noinline __be32 *xdr_get_next_encode_buffer(struct xdr_stream *xdr, if (space_left - nbytes >= PAGE_SIZE) xdr->end = p + PAGE_SIZE; else - xdr->end = p + space_left - frag1bytes; + xdr->end = p + min_t(int, space_left - frag1bytes, PAGE_SIZE); xdr->buf->page_len += frag2bytes; xdr->buf->len += nbytes;