Received: by 2002:ab2:7a55:0:b0:1f4:4a7d:290d with SMTP id u21csp323419lqp; Thu, 4 Apr 2024 14:30:35 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVWhgRlAOj90vyBjUSwNNshndfrah5MVL37rbZy9SYRbl/GtUTB7QIERsr9TIbxPEvabZbY5Rjm2qfZDRG7ZyCpnLAeOAEtQyv1F/VDIg== X-Google-Smtp-Source: AGHT+IEm10NDROx2XeNb4FHeVy2NF4oX8Y85fizGs61vObF0/ihIe8xcHaye8L+8qfqLn8wm//zS X-Received: by 2002:a17:90b:78b:b0:2a2:b5dd:b20d with SMTP id l11-20020a17090b078b00b002a2b5ddb20dmr966872pjz.20.1712266234632; Thu, 04 Apr 2024 14:30:34 -0700 (PDT) Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id ck12-20020a17090afe0c00b002a25408f855si2282504pjb.157.2024.04.04.14.30.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Apr 2024 14:30:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-132160-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@infradead.org header.s=casper.20170209 header.b=d1g8oWeT; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-132160-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-132160-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 50AEF28A016 for ; Thu, 4 Apr 2024 21:30:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1DFA713C3C9; Thu, 4 Apr 2024 21:29:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="d1g8oWeT" Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D8EC813BACF; Thu, 4 Apr 2024 21:29:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712266165; cv=none; b=B9uwEs7oU4nGLGx+6/JrdS/s+og0nPtC15ZFquFGz7/SIZiv3QB74TXFdguVsz67pCg36SKXzX21EKPHqEEmFJPigp/np0wqxO6om0D5+FfSkqF95w0CvVJkvsXvbPvhNyUB0UXqnWdiP1PmQtt9Ko9JU3Ox1WCqqG8uIt9dQK4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712266165; c=relaxed/simple; bh=Utj8g5kSIY2oZzcEMi6QXW1D/5gc1CLBmlqTBBy6/AM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lUlgkdjk/HlF00OSdbkpWs3XMJxNbiAFUWUv2D8E+Q6zKljZNBcRpaXfv9UXckj2USTSNtmNeA0BMnDivzGXhypZUXFhf2rcxJGcjozU8wv0kAJ6vkEIP5txtc1s2JT67+upBK/d4l2SHUJ45BVacJVuIlNxV/UE3C4PLxXKy6Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=d1g8oWeT; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Zyi7AEcYnfqB6wuIN5C5labJ5TkiPsioxAOKz/6Fbqs=; b=d1g8oWeT9rYHBlZuF9xsTFDFHG 4lSJo/KGw64j3qekI4UzOPIXJ1k3xqp49kuQDsjI3KWu1PeNyrvAx32gduojBtJnubIYbpR8ATH9/ iHi0XgwD4MRWgBREvdk6kwWIJMIJufuG2rvsYSbhZahYCtFlqfUHZoB/9OG3i+HKLm5pf24AQ/JN2 9SFsSEsuALRsGWBL8WIAgLr6AWItvY3OcojGDkbhHZsDqZ1XuYyScYDs1+aUQs9aWl8qV9+jLJ+tV tJCk+/43dla/bl5lv45MJp+W8A/geOJcFQ8gjN3XZ0JwVqHcOjoTgz3o0Y9HJuAjDwX2Jd5ldJTru 2h94r9pw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rsUe5-00000008veN-2BP2; Thu, 04 Apr 2024 21:29:17 +0000 Date: Thu, 4 Apr 2024 22:29:17 +0100 From: Matthew Wilcox To: Kees Cook Cc: Jan Kara , Chuck Lever , "Gustavo A . R . Silva" , Christian Brauner , Alexander Viro , Jeff Layton , Amir Goldstein , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] fs: Set file_handle::handle_bytes before referencing file_handle::f_handle Message-ID: References: <20240404211212.it.297-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240404211212.it.297-kees@kernel.org> On Thu, Apr 04, 2024 at 02:12:15PM -0700, Kees Cook wrote: > Since __counted_by(handle_bytes) was added to struct file_handle, we need > to explicitly set it in the one place it wasn't yet happening prior to > accessing the flex array "f_handle". For robustness also check for a > negative value for handle_bytes, which is possible for an "int", but > nothing appears to set. Why not change handle_bytes from an int to a u32? Also, what a grotty function. handle_dwords = f_handle.handle_bytes >> 2; .. handle_bytes = handle_dwords * sizeof(u32); > Fixes: 1b43c4629756 ("fs: Annotate struct file_handle with __counted_by() and use struct_size()") > Signed-off-by: Kees Cook > --- > Cc: Jan Kara > Cc: Chuck Lever > Cc: Gustavo A. R. Silva > Cc: Christian Brauner > Cc: Alexander Viro > Cc: Jeff Layton > Cc: Amir Goldstein > Cc: linux-fsdevel@vger.kernel.org > Cc: linux-nfs@vger.kernel.org > Cc: linux-hardening@vger.kernel.org > v2: more bounds checking, add comments, dropped reviews since logic changed > v1: https://lore.kernel.org/all/20240403215358.work.365-kees@kernel.org/ > --- > fs/fhandle.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/fs/fhandle.c b/fs/fhandle.c > index 8a7f86c2139a..854f866eaad2 100644 > --- a/fs/fhandle.c > +++ b/fs/fhandle.c > @@ -40,6 +40,11 @@ static long do_sys_name_to_handle(const struct path *path, > GFP_KERNEL); > if (!handle) > return -ENOMEM; > + /* > + * Since handle->f_handle is about to be written, make sure the > + * associated __counted_by(handle_bytes) variable is correct. > + */ > + handle->handle_bytes = f_handle.handle_bytes; > > /* convert handle size to multiple of sizeof(u32) */ > handle_dwords = f_handle.handle_bytes >> 2; > @@ -51,8 +56,8 @@ static long do_sys_name_to_handle(const struct path *path, > handle->handle_type = retval; > /* convert handle size to bytes */ > handle_bytes = handle_dwords * sizeof(u32); > - handle->handle_bytes = handle_bytes; > - if ((handle->handle_bytes > f_handle.handle_bytes) || > + /* check if handle_bytes would have exceeded the allocation */ > + if ((handle_bytes < 0) || (handle_bytes > f_handle.handle_bytes) || > (retval == FILEID_INVALID) || (retval < 0)) { > /* As per old exportfs_encode_fh documentation > * we could return ENOSPC to indicate overflow > @@ -68,6 +73,8 @@ static long do_sys_name_to_handle(const struct path *path, > handle_bytes = 0; > } else > retval = 0; > + /* the "valid" number of bytes may fewer than originally allocated */ > + handle->handle_bytes = handle_bytes; > /* copy the mount id */ > if (put_user(real_mount(path->mnt)->mnt_id, mnt_id) || > copy_to_user(ufh, handle, > -- > 2.34.1 > >