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;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Jeff Layton <jlayton@kernel.org>
CC:     Bruce Fields <bfields@fieldses.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Jan Kasiak <j.kasiak@gmail.com>
Subject: Re: [PATCH v2] lockd: detect and reject lock arguments that overflow
Thread-Topic: [PATCH v2] lockd: detect and reject lock arguments that overflow
Thread-Index: AQHYpeDywRmd2Ah7M0OUhDyIIRvMH62bp2IAgAAbKgCAAAGMAA==
Date:   Tue, 2 Aug 2022 15:52:54 +0000
Message-ID: <07E1B05E-B611-4831-95BD-962C7C378675@oracle.com>
References: <20220801195726.154229-1-jlayton@kernel.org>
 <D34C84D6-B1BA-4200-9879-B0AD6CE8AB00@oracle.com>
 <643b9dc1976a24a65cb6160ce3e16c57afa59b84.camel@kernel.org>
In-Reply-To: <643b9dc1976a24a65cb6160ce3e16c57afa59b84.camel@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QvKSSLsDRL4qCGrlHazyCe7DnI6iqRfBsgb4hCrVeFV0N5PqBklKumC1SQMW?=
 =?us-ascii?Q?veGEUNQh6mHml1watfnGXU9Ke2UYeRIBlXYmOJeTJBi2tenFKSmexWWdxvju?=
 =?us-ascii?Q?sjmGTIWAKyqzYDfjk3YKi66munOTKf223PRiOpUvIuUr3JGygj3BLj2LT6ZM?=
 =?us-ascii?Q?qE0GFwoxAMklP7ZRJIJfqX7FozxY+Xo38uluJOQ3jFgAW/XfZvdAOUy465/k?=
 =?us-ascii?Q?hWAGcHeY6oP4vYwnjc6WLKK0Dy/mgawBoXX08sT85nkDRmBKbnnw+Vv/dyX1?=
 =?us-ascii?Q?w3PLg4Z/klmGHirsba8BFbDTBMHjsk/YK1hgq0NloQ+Dl3MKOnJEUKlBqtHE?=
 =?us-ascii?Q?WJN94MVdZ0Nnt2GioRnRZvkwGnphfoWPHMdChhvftWVCo7ZaJUK4H/VavQY+?=
 =?us-ascii?Q?J8SoqRpi/X1C59w8S2NfCtawASE8obZGWT2c2h1nfUrZCkiijVblqak3NfJx?=
 =?us-ascii?Q?6mdcfBKMHVikarOkVVGvovOz6OnyHYHzUyBDsXxMasYRl7XqjFqmAYLhmuRF?=
 =?us-ascii?Q?2lg4BAys1gnSZMMpPZ24HcFbDWbTRlU0KQLZ6qSSMv8C4SYqMQ1+3sHja7MO?=
 =?us-ascii?Q?9gRws1T0lnBnqKPZT7qC/UtRmjdhvjrXNJGOXvumUNzs0Kn8omon352UqCfN?=
 =?us-ascii?Q?fiZv905faXjafO56ZILIMYchv/mrasV12b4scAl0c7SUsYYfNgYy+qnZbJty?=
 =?us-ascii?Q?w+M4Y1o0V3/I/aeuwmBpzXRcojjUTtFtAgwyGKhS9oDn3k/7i9rdFDDmeRVW?=
 =?us-ascii?Q?cQGUOFmc8sZzYTq99ZgD/JNbBetVJQOmf6xWeyNCQoTy8pYvg79C9OYsacUt?=
 =?us-ascii?Q?MLYzut3/Swi1WioloQXZATKKvSIZ+prHgL5H61dwrGr9MnIq8CrQyYzyOiOR?=
 =?us-ascii?Q?Qo9sIgcyKJIFm5ERuAmxVGEdAt14x+nR/UYV81qflC293yfEjLpz7gmU3CYH?=
 =?us-ascii?Q?c6NTkYU+tpPeewqwRGovJRhmsh5RBPhhizOble9quvoFZfRGAZbyv+/JQqzk?=
 =?us-ascii?Q?PBYXTRLULHb6xYYhHohT4V8wrFoKuvqlWzaqaPfZNkCGha5B+l4laopAZ4yq?=
 =?us-ascii?Q?5kLT78rrNSYtBn/SJHtwDHLsQPdCrRIjD97VcRcFGcfCQqZuqIiFfGkIBaqe?=
 =?us-ascii?Q?98rBgK1WOZZ9MyAlpl7NfDqg39r56ejE3BI732NGIA+a/ziCQBVGxQRub0wK?=
 =?us-ascii?Q?KE5pVNy4Xs/w+79rTzHhovEbHRoAUk8Y3KaGNInyUpcoayHZam+m5JAyDWux?=
 =?us-ascii?Q?D29fi5A0OJDI3/p05be2VwufvtlxDy/eD59VBnZmYXQfQm0Pf6OiAJ/OLLz5?=
 =?us-ascii?Q?D2iO0Rt753xBpqGK1DBlCMhOmMn0C7JY7E28OHBc5zk+QfmWF8YeuL4Eknf0?=
 =?us-ascii?Q?uO8o079/JywCCJxM1nogGkWwGSru7JWfD4DXmTAqyDjDOAV8X3SvKi875uvC?=
 =?us-ascii?Q?2UsCqP3kA3yc+Q8BnD9lVqGPc/jIs7BVHPhG4hOPI3bFdAirnFlbDlL6Hxw4?=
 =?us-ascii?Q?EKAkrhcgo+W4VKKKI9ns8btOxjopHmem5YFdZOsFvJjHYyrXnmwe8iiVYLbs?=
 =?us-ascii?Q?aEnBohWEXr3eqOfYfvuYpY08A7gFUC+MRl6TKU7vZs8mHliRRu/KBHU2bJSs?=
 =?us-ascii?Q?yA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6193D47264C42B40AFCD5553779CAC76@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 99c2533c-d071-4c77-5c0f-08da749f1031
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2022 15:52:54.6482
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lMv9Xbsd8G3ZPk+kTSAjzKtVK3LWnBK3+PrtoIbHbqCr8Et8KtjLM9Bghfuqs6pP8sQd0RMP9dE9h+aDGiCuOQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2782
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-08-02_11,2022-08-02_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 phishscore=0
 malwarescore=0 suspectscore=0 spamscore=0 adultscore=0 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000
 definitions=main-2208020074
X-Proofpoint-GUID: fJ6XPNXovtYxxGEHFlyp-0nzELIxAu1x
X-Proofpoint-ORIG-GUID: fJ6XPNXovtYxxGEHFlyp-0nzELIxAu1x
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Aug 2, 2022, at 11:47 AM, Jeff Layton <jlayton@kernel.org> wrote:
>=20
> On Tue, 2022-08-02 at 14:10 +0000, Chuck Lever III wrote:
>>=20
>>> On Aug 1, 2022, at 3:57 PM, Jeff Layton <jlayton@kernel.org> wrote:
>>>=20
>>> 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.
>>>=20
>>> 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 wa=
s
>>> an overflow.
>>>=20
>>> 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.
>>>=20
>>> Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=3D392
>>> Reported-by: Jan Kasiak <j.kasiak@gmail.com>
>>> Signed-off-by: Jeff Layton <jlayton@kernel.org>
>>=20
>> I've applied this one to my private tree for testing.
>> Thanks Jeff!
>>=20
>>=20
>=20
> Thank you. We should probably also consider sending this to stable
> kernels too. It's at least a DoS vector.

Agreed, though it won't apply before 345b4159a075 ("lockd: Update
the NLMv4 TEST arguments decoder to use struct xdr_stream")

How about:

Cc: <stable@vger.kernel.org> # 5.14

?


>>> ---
>>> fs/lockd/svc4proc.c       |  8 ++++++++
>>> fs/lockd/xdr4.c           | 19 ++-----------------
>>> include/linux/lockd/xdr.h |  2 ++
>>> 3 files changed, 12 insertions(+), 17 deletions(-)
>>>=20
>>> v2: record args as u64s in nlm_lock and check them in
>>>   nlm4svc_retrieve_args
>>>=20
>>> diff --git a/fs/lockd/svc4proc.c b/fs/lockd/svc4proc.c
>>> index 176b468a61c7..e5adb524a445 100644
>>> --- a/fs/lockd/svc4proc.c
>>> +++ b/fs/lockd/svc4proc.c
>>> @@ -32,6 +32,10 @@ nlm4svc_retrieve_args(struct svc_rqst *rqstp, struct=
 nlm_args *argp,
>>> 	if (!nlmsvc_ops)
>>> 		return nlm_lck_denied_nolocks;
>>>=20
>>> +	if (lock->lock_start > OFFSET_MAX ||
>>> +	    (lock->lock_len && ((lock->lock_len - 1) > (OFFSET_MAX - lock->lo=
ck_start))))
>>> +		return nlm4_fbig;
>>> +
>>> 	/* Obtain host handle */
>>> 	if (!(host =3D nlmsvc_lookup_host(rqstp, lock->caller, lock->len))
>>> 	 || (argp->monitor && nsm_monitor(host) < 0))
>>> @@ -50,6 +54,10 @@ nlm4svc_retrieve_args(struct svc_rqst *rqstp, struct=
 nlm_args *argp,
>>> 		/* Set up the missing parts of the file_lock structure */
>>> 		lock->fl.fl_file  =3D file->f_file[mode];
>>> 		lock->fl.fl_pid =3D current->tgid;
>>> +		lock->fl.fl_start =3D (loff_t)lock->lock_start;
>>> +		lock->fl.fl_end =3D lock->lock_len ?
>>> +				   (loff_t)(lock->lock_start + lock->lock_len - 1) :
>>> +				   OFFSET_MAX;
>>> 		lock->fl.fl_lmops =3D &nlmsvc_lock_operations;
>>> 		nlmsvc_locks_init_private(&lock->fl, host, (pid_t)lock->svid);
>>> 		if (!lock->fl.fl_owner) {
>>> diff --git a/fs/lockd/xdr4.c b/fs/lockd/xdr4.c
>>> index 856267c0864b..712fdfeb8ef0 100644
>>> --- a/fs/lockd/xdr4.c
>>> +++ b/fs/lockd/xdr4.c
>>> @@ -20,13 +20,6 @@
>>>=20
>>> #include "svcxdr.h"
>>>=20
>>> -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 =3D &lock->fl;
>>> -	u64 len, start;
>>> -	s64 end;
>>>=20
>>> 	if (!svcxdr_decode_string(xdr, &lock->caller, &lock->len))
>>> 		return false;
>>> @@ -81,20 +72,14 @@ svcxdr_decode_lock(struct xdr_stream *xdr, struct n=
lm_lock *lock)
>>> 		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;
>>>=20
>>> 	locks_init_lock(fl);
>>> 	fl->fl_flags =3D FL_POSIX;
>>> 	fl->fl_type  =3D F_RDLCK;
>>> -	end =3D start + len - 1;
>>> -	fl->fl_start =3D s64_to_loff_t(start);
>>> -	if (len =3D=3D 0 || end < 0)
>>> -		fl->fl_end =3D OFFSET_MAX;
>>> -	else
>>> -		fl->fl_end =3D s64_to_loff_t(end);
>>>=20
>>> 	return true;
>>> }
>>> diff --git a/include/linux/lockd/xdr.h b/include/linux/lockd/xdr.h
>>> index 398f70093cd3..67e4a2c5500b 100644
>>> --- 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;
>>> };
>>>=20
>>> --=20
>>> 2.37.1
>>>=20
>>=20
>> --
>> Chuck Lever
>>=20
>>=20
>>=20
>=20
> --=20
> Jeff Layton <jlayton@kernel.org>

--
Chuck Lever