Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp2928467rwb; Mon, 15 Aug 2022 14:14:05 -0700 (PDT) X-Google-Smtp-Source: AA6agR4nRO9R76L2HF6sJel6sC2IyTcj/kFtg1OSSE/RB8Jws11geZ5JZThQec4HEgexdiguDvD6 X-Received: by 2002:a17:902:e5c4:b0:16e:d968:6352 with SMTP id u4-20020a170902e5c400b0016ed9686352mr19262932plf.69.1660598044813; Mon, 15 Aug 2022 14:14:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660598044; cv=none; d=google.com; s=arc-20160816; b=opWSLm/qx7mDSnfLQ2Efp8TZ+Nn5n7lyRK+FrswKknx6AJ/2OvduWrAuyPUQQ/1Dyc BD9/6eI5bpwOoP3n9fnQkei4uSLCleKOYwUzZIfNhILm+UEW9AYqS/vMhldgS05yrVg4 eN4G2r9r+J8I9Z/o0AqyShfA40aAFNsiqHamvlBHG5vvGHvLNsPiwwMeO5esaB4bk7EG w2VwBNFNC33GNYUylx3x8Vgs7jWTvJRJM7VaaJv7Qkb2DSjUi1+hibgU/wWB866vmTZF fzDOXBd+XJ/fszxuitcgwzHAhujY6TE0avjONE3lrSWRZFS1vu/wVHzTcQUTAoCjres6 DIgA== 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:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=qQsaCFUAv3IqmmJ1f91gIM45eMctXM0q1koamRqmdcU=; b=XlR72vFS5xZQfZrpr7JE5K7HHTnhepCoCk0hA+JqTWwceihFleJ0eRPEoJJX2/B7Hz Ir+XYgnQNGwAa1Q3QeQ4w1UGiAMrRqAavMmNfnY1NjfJ6BRfFMOxnCgLrhzGmWFD+jVl RkwlSxXrVAgOHmJs4gBLjGoQ/OJv+JkXR1M6mUBHfKgckyjoOWOvCVNc8MWDK3KPSlwQ e5O5bmP70yGqZ2VF3zXwzFLD/u9g6czE5pclXHmA0gNa1eshRRSa1uGUpLgMJ3OMRY4z qXpQ8kOhrxDSTALf8vCimOBdJI3qNKu+T3kq9/u2A1JPRhMib2SpbV1xQrsiYSTRwHtM ww+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Dno4jnR6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 17-20020a631651000000b0041e27a782a5si12595582pgw.144.2022.08.15.14.13.53; Mon, 15 Aug 2022 14:14:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Dno4jnR6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242689AbiHOUHY (ORCPT + 99 others); Mon, 15 Aug 2022 16:07:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345997AbiHOUFz (ORCPT ); Mon, 15 Aug 2022 16:05:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE5E880F73; Mon, 15 Aug 2022 11:54:59 -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 5176BB810A0; Mon, 15 Aug 2022 18:54:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B921C433C1; Mon, 15 Aug 2022 18:54:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660589690; bh=2aMAS6nnDE24Xxc3BAWnHHAWPjrQi/Hpa0MkJi+LjSc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dno4jnR6SlUp2YUQG245vrG4siDJafxSjea1TMs3LxAUWiPvGraXhuBgEG3S8/LUg jl4KNl1hzHsUZbu4ZaZbNMCoSw0ctjqYRpu685LuIhShL5GyIG9HEQdsY4PM59xHWa QJcQMlLKycjyzvZzG+43vVQrVgNzTr1clRt5vPr4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jan Kasiak , Jeff Layton , Chuck Lever Subject: [PATCH 5.18 0018/1095] lockd: detect and reject lock arguments that overflow Date: Mon, 15 Aug 2022 19:50:17 +0200 Message-Id: <20220815180430.097981703@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220815180429.240518113@linuxfoundation.org> References: <20220815180429.240518113@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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-kernel@vger.kernel.org From: Jeff Layton commit 6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde upstream. lockd doesn't currently vet the start and length in nlm4 requests like it should, and can end up generating lock requests with arguments that overflow when passed to the filesystem. The NLM4 protocol uses unsigned 64-bit arguments for both start and length, whereas struct file_lock tracks the start and end as loff_t values. By the time we get around to calling nlm4svc_retrieve_args, we've lost the information that would allow us to determine if there was an overflow. Start tracking the actual start and len for NLM4 requests in the nlm_lock. In nlm4svc_retrieve_args, vet these values to ensure they won't cause an overflow, and return NLM4_FBIG if they do. Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=392 Reported-by: Jan Kasiak Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Cc: # 5.14+ Signed-off-by: Greg Kroah-Hartman --- fs/lockd/svc4proc.c | 8 ++++++++ fs/lockd/xdr4.c | 19 ++----------------- include/linux/lockd/xdr.h | 2 ++ 3 files changed, 12 insertions(+), 17 deletions(-) --- a/fs/lockd/svc4proc.c +++ b/fs/lockd/svc4proc.c @@ -32,6 +32,10 @@ nlm4svc_retrieve_args(struct svc_rqst *r if (!nlmsvc_ops) return nlm_lck_denied_nolocks; + if (lock->lock_start > OFFSET_MAX || + (lock->lock_len && ((lock->lock_len - 1) > (OFFSET_MAX - lock->lock_start)))) + return nlm4_fbig; + /* Obtain host handle */ if (!(host = nlmsvc_lookup_host(rqstp, lock->caller, lock->len)) || (argp->monitor && nsm_monitor(host) < 0)) @@ -50,6 +54,10 @@ nlm4svc_retrieve_args(struct svc_rqst *r /* Set up the missing parts of the file_lock structure */ lock->fl.fl_file = file->f_file[mode]; lock->fl.fl_pid = current->tgid; + lock->fl.fl_start = (loff_t)lock->lock_start; + lock->fl.fl_end = lock->lock_len ? + (loff_t)(lock->lock_start + lock->lock_len - 1) : + OFFSET_MAX; lock->fl.fl_lmops = &nlmsvc_lock_operations; nlmsvc_locks_init_private(&lock->fl, host, (pid_t)lock->svid); if (!lock->fl.fl_owner) { --- a/fs/lockd/xdr4.c +++ b/fs/lockd/xdr4.c @@ -20,13 +20,6 @@ #include "svcxdr.h" -static inline loff_t -s64_to_loff_t(__s64 offset) -{ - return (loff_t)offset; -} - - static inline s64 loff_t_to_s64(loff_t offset) { @@ -70,8 +63,6 @@ static bool svcxdr_decode_lock(struct xdr_stream *xdr, struct nlm_lock *lock) { struct file_lock *fl = &lock->fl; - u64 len, start; - s64 end; if (!svcxdr_decode_string(xdr, &lock->caller, &lock->len)) return false; @@ -81,20 +72,14 @@ svcxdr_decode_lock(struct xdr_stream *xd return false; if (xdr_stream_decode_u32(xdr, &lock->svid) < 0) return false; - if (xdr_stream_decode_u64(xdr, &start) < 0) + if (xdr_stream_decode_u64(xdr, &lock->lock_start) < 0) return false; - if (xdr_stream_decode_u64(xdr, &len) < 0) + if (xdr_stream_decode_u64(xdr, &lock->lock_len) < 0) return false; locks_init_lock(fl); fl->fl_flags = FL_POSIX; fl->fl_type = F_RDLCK; - end = start + len - 1; - fl->fl_start = s64_to_loff_t(start); - if (len == 0 || end < 0) - fl->fl_end = OFFSET_MAX; - else - fl->fl_end = s64_to_loff_t(end); return true; } --- a/include/linux/lockd/xdr.h +++ b/include/linux/lockd/xdr.h @@ -41,6 +41,8 @@ struct nlm_lock { struct nfs_fh fh; struct xdr_netobj oh; u32 svid; + u64 lock_start; + u64 lock_len; struct file_lock fl; };