Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3479976ybg; Fri, 25 Oct 2019 04:53:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqwpgcd9iTHIaboQO8o90gU6NdfJOLnUOMSLgsk0domCqXH/yInMD74U7YX6+SWAMlFYP3Xr X-Received: by 2002:a50:aadc:: with SMTP id r28mr3423809edc.107.1572004436670; Fri, 25 Oct 2019 04:53:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572004436; cv=none; d=google.com; s=arc-20160816; b=CaYiwlO+g00lNWPQK/964iaK1aRpYfh+HR8bVbAEv1O7s9Y0cYNEZ+kdEWkofUeTwk gM9tHPWZ/WHJ9S44OgA8QAuk+5tHNLjMvLnDk5/yyvFEONdELK7OVIU/FSxNpsasEp+O njiY0RJMft5ErYVjrOzh875UWbhkond9z5okKS1Y/scPMVDRbf8nJTl3tCS+M1gZqybu B6+ETWZ9d+YTz4SZwFedQXwScPE4hn/Yam7yIg7rKJtSZCrVgc/16CJXNR+CxSnMfey6 EesrwC9E9XJqf1cdScWXlViIWEH3T86/fWL1t2K317oqn40ZAd7WCHzNAbwXxspvl59Z YdxA== 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:mime-version :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature; bh=PwyIfieXLA62s7tDCjayDWRAXO/gqA5QXmEp5ciJTRY=; b=lBnm5cevXHLJ88pup3+m7pxN2XcW+7bJ/c3okFcVOPzIktC0Xqs6B3c4wR7diibJYw IJrLIjDJGn7NkIS0VvIdNzx+KcvToq6Dqt7zedn9cGyLROKggU8KnMQ7aQ20GZNo1Hhs 7Jmi2Y6YpMY14x8zw6Qa8lifHMX2+FqewYp5v8HRcIfNya6b3vkDHBUKwS2fSChj5r7J 2IWVTIzfSHkITOK5PPjeh65rISbaY+NpzHqWtSoTHP/AEUjTZIBMXUDuazgVKZLjs+nA gt4XH9LQ75g0fJMynH9Qu/AGqlNUsaAPzALF2xiRW6VnM9gqv5Na5Ae9lYUf7fgvfVbO Og3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b="YO8N/wb2"; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 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 vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w25si1091940ejn.391.2019.10.25.04.53.32; Fri, 25 Oct 2019 04:53:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b="YO8N/wb2"; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 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 S2393587AbfJXNeT (ORCPT + 99 others); Thu, 24 Oct 2019 09:34:19 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:33273 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388422AbfJXNeT (ORCPT ); Thu, 24 Oct 2019 09:34:19 -0400 Received: by mail-io1-f66.google.com with SMTP id z19so29555410ior.0 for ; Thu, 24 Oct 2019 06:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=PwyIfieXLA62s7tDCjayDWRAXO/gqA5QXmEp5ciJTRY=; b=YO8N/wb2LoCvc/NiC6nmZDc3uyYuVdBs4r3CeRMaCtphIa/O+SClGH1joDoUhO1HIG tZBawHjPGJdxTQRhI6nBQ18u76RVYANszF+gFTQYS0aUvwpFtoZ7MaSbUCTc2+92jt+j fI36Cyfvtlgtt+lVadazGh6xf7l4yWoNVzsCQDO59MpAtqGW+POd99bmAHfdthV7Am6b JTRuYr7czKRuZqs1h3pXvFDWlHWRhF0l2Qjw1s6tI7hVM01ChNVl/dZLTrmqiIQ3PdeL SAEMA76Uv6uVZYidsBLKth3wBOSxnshBozMlkwKEMv/idKRmbvRjbog1HAn4ev8uS8Eg w+Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:date:message-id :in-reply-to:references:user-agent:mime-version :content-transfer-encoding; bh=PwyIfieXLA62s7tDCjayDWRAXO/gqA5QXmEp5ciJTRY=; b=pxyKWKUDEgiwE4Rw42h+mOgmCW5z6w95pw8/YnDvOOzMV4ZT0+fQGTKuYmy2yZQzAJ LXEwQmKSQ47P4hgHpVxc+/EunY8N1wz135jgFJVDU6Ox2LxQQSTSg0oNDRgj80BiC8z7 oyiMAlltE5UKAwk7Bff8D4I0LDLnPhqUehtia0B8Rx6MV8qChS7xF4w5Byq1OiOgp2Y9 Bc3v3tbZFh9GYywkq4ECuB9bJbF2x1Wk2TSusbjLmnaFUxdxOErUa02KghZ975+zhVkM SxhryjI5OWYtybsl8qY5TT2FmuBZjdpoBMhd2UfV2nSZpXSMxd+7ChBhpKPLkQHZ/N1I 7S1A== X-Gm-Message-State: APjAAAXbbJyXqKeGWAih1YUoH3QKEBkHAqvow+UDM9iuQR7FpW/QPont WRtkOdAJ9ZlDfcpfSlVQl/P50qpG X-Received: by 2002:a6b:610b:: with SMTP id v11mr8817276iob.219.1571924058446; Thu, 24 Oct 2019 06:34:18 -0700 (PDT) Received: from gateway.1015granger.net (c-68-61-232-219.hsd1.mi.comcast.net. [68.61.232.219]) by smtp.gmail.com with ESMTPSA id x64sm3156788ill.75.2019.10.24.06.34.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Oct 2019 06:34:17 -0700 (PDT) Received: from klimt.1015granger.net (klimt.1015granger.net [192.168.1.55]) by gateway.1015granger.net (8.14.7/8.14.7) with ESMTP id x9ODYGiw015341; Thu, 24 Oct 2019 13:34:16 GMT Subject: [PATCH v1 2/2] SUNRPC: Fix svcauth_gss_proxy_init() From: Chuck Lever To: bfields@fieldses.org Cc: linux-nfs@vger.kernel.org Date: Thu, 24 Oct 2019 09:34:16 -0400 Message-ID: <20191024133416.2148.96218.stgit@klimt.1015granger.net> In-Reply-To: <20191024133410.2148.3456.stgit@klimt.1015granger.net> References: <20191024133410.2148.3456.stgit@klimt.1015granger.net> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org gss_read_proxy_verf() assumes things about the XDR buffer containing the RPC Call that are not true for buffers generated by svc_rdma_recv(). RDMA's buffers look more like what the upper layer generates for sending: head is a kmalloc'd buffer; it does not point to a page whose contents are contiguous with the first page in the buffers' page array. The result is that ACCEPT_SEC_CONTEXT via RPC/RDMA has stopped working on Linux NFS servers that use gssproxy. This does not affect clients that use only TCP to send their ACCEPT_SEC_CONTEXT operation (that's all Linux clients). Other clients, like Solaris NFS clients, send ACCEPT_SEC_CONTEXT on the same transport as they send all other NFS operations. Such clients can send ACCEPT_SEC_CONTEXT via RPC/RDMA. I thought I had found every direct reference in the server RPC code to the rqstp->rq_pages field. Bug found at the 2019 Westford NFS bake-a-thon. Fixes: 3316f0631139 ("svcrdma: Persistently allocate and DMA- ... ") Signed-off-by: Chuck Lever Tested-by: Bill Baker --- net/sunrpc/auth_gss/svcauth_gss.c | 84 ++++++++++++++++++++++++++++--------- 1 file changed, 63 insertions(+), 21 deletions(-) diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c index f130990..c62d1f1 100644 --- a/net/sunrpc/auth_gss/svcauth_gss.c +++ b/net/sunrpc/auth_gss/svcauth_gss.c @@ -1078,24 +1078,32 @@ struct gss_svc_data { return 0; } -/* Ok this is really heavily depending on a set of semantics in - * how rqstp is set up by svc_recv and pages laid down by the - * server when reading a request. We are basically guaranteed that - * the token lays all down linearly across a set of pages, starting - * at iov_base in rq_arg.head[0] which happens to be the first of a - * set of pages stored in rq_pages[]. - * rq_arg.head[0].iov_base will provide us the page_base to pass - * to the upcall. - */ -static inline int -gss_read_proxy_verf(struct svc_rqst *rqstp, - struct rpc_gss_wire_cred *gc, __be32 *authp, - struct xdr_netobj *in_handle, - struct gssp_in_token *in_token) +static void gss_free_in_token_pages(struct gssp_in_token *in_token) { - struct kvec *argv = &rqstp->rq_arg.head[0]; u32 inlen; - int res; + int i; + + i = 0; + inlen = in_token->page_len; + while (inlen) { + if (in_token->pages[i]) + put_page(in_token->pages[i]); + inlen -= inlen > PAGE_SIZE ? PAGE_SIZE : inlen; + } + + kfree(in_token->pages); + in_token->pages = NULL; +} + +static int gss_read_proxy_verf(struct svc_rqst *rqstp, + struct rpc_gss_wire_cred *gc, __be32 *authp, + struct xdr_netobj *in_handle, + struct gssp_in_token *in_token) +{ + struct kvec *argv = &rqstp->rq_arg.head[0]; + unsigned int page_base, length; + int pages, i, res; + size_t inlen; res = gss_read_common_verf(gc, argv, authp, in_handle); if (res) @@ -1105,10 +1113,36 @@ struct gss_svc_data { if (inlen > (argv->iov_len + rqstp->rq_arg.page_len)) return SVC_DENIED; - in_token->pages = rqstp->rq_pages; - in_token->page_base = (ulong)argv->iov_base & ~PAGE_MASK; + pages = DIV_ROUND_UP(inlen, PAGE_SIZE); + in_token->pages = kcalloc(pages, sizeof(struct page *), GFP_KERNEL); + if (!in_token->pages) + return SVC_DENIED; + in_token->page_base = 0; in_token->page_len = inlen; + for (i = 0; i < pages; i++) { + in_token->pages[i] = alloc_page(GFP_KERNEL); + if (!in_token->pages[i]) { + gss_free_in_token_pages(in_token); + return SVC_DENIED; + } + } + length = min_t(unsigned int, inlen, argv->iov_len); + memcpy(page_address(in_token->pages[0]), argv->iov_base, length); + inlen -= length; + + i = 1; + page_base = rqstp->rq_arg.page_base; + while (inlen) { + length = min_t(unsigned int, inlen, PAGE_SIZE); + memcpy(page_address(in_token->pages[i]), + page_address(rqstp->rq_arg.pages[i]) + page_base, + length); + + inlen -= length; + page_base = 0; + i++; + } return 0; } @@ -1282,8 +1316,11 @@ static int svcauth_gss_proxy_init(struct svc_rqst *rqstp, break; case GSS_S_COMPLETE: status = gss_proxy_save_rsc(sn->rsc_cache, &ud, &handle); - if (status) + if (status) { + pr_info("%s: gss_proxy_save_rsc failed (%d)\n", + __func__, status); goto out; + } cli_handle.data = (u8 *)&handle; cli_handle.len = sizeof(handle); break; @@ -1294,15 +1331,20 @@ static int svcauth_gss_proxy_init(struct svc_rqst *rqstp, /* Got an answer to the upcall; use it: */ if (gss_write_init_verf(sn->rsc_cache, rqstp, - &cli_handle, &ud.major_status)) + &cli_handle, &ud.major_status)) { + pr_info("%s: gss_write_init_verf failed\n", __func__); goto out; + } if (gss_write_resv(resv, PAGE_SIZE, &cli_handle, &ud.out_token, - ud.major_status, ud.minor_status)) + ud.major_status, ud.minor_status)) { + pr_info("%s: gss_write_resv failed\n", __func__); goto out; + } ret = SVC_COMPLETE; out: + gss_free_in_token_pages(&ud.in_token); gssp_free_upcall_data(&ud); return ret; }