From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 2B7953DBD4A for ; Thu, 2 Apr 2026 12:07:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775131622; cv=none; b=qLUPXprzZdMfjoEwjJlm27H/w3BXnQiJSsErQysnEMY8EVfvEtWAlfwnmRghk2d4Ce+jNGRiU43pmu+LO8ih7ATW+cIRdbYq+7n984ko2nU+54PAQXJkGpPRVFkDWg3GHlvSie2SVIp5Yd1yARPk+4si9IDUDFQ1NRNPNqN+Krg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775131622; c=relaxed/simple; bh=0YRJDY0hlF0nvCzgbpge69pz9CdJ/F2OpbMew3Md154=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=uIwv5L4ntoda5D5+OsuXfYVNnXLiCXTIvT+9bvtKJYOkuwgM9ysrINJoo/po2hSTPgKG8pMvVi6wN5fdmD19p4DHbkjmXEYNZGtOfwJ9MbkKYaUf1ckXKU4K/V6zXH0ovUNijl6zhIbBEGtWbQmIDFAkub2EB0uEb/jN+CunK7E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G1ar6JDJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G1ar6JDJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D0F8C19423; Thu, 2 Apr 2026 12:06:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775131621; bh=0YRJDY0hlF0nvCzgbpge69pz9CdJ/F2OpbMew3Md154=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G1ar6JDJ7+Y4ix6kgBRCWPVO4hlNkcPXbqmeYWcUT9OzK/1pCvYkCljSGnZEROccZ 9g2xWjUqFx+RbMEObRj2J0ZbiPLDHZoJa6OtSoa3DfwU8jfrlDVNuKPU7R/zX8Ikgq eT77oYOTWoc2yq3SEkwoPnoL+Vv7W+zCaZCZQZsPx9HTGhgpR249xpXF4g+1iDHO+Z Pz0lidg+qDO5POkRgbElAFdYVXxwBYh7xhsa4zHAOtOVXpRc+5oJLpEmNJ8m/euGVM zd69mHrF8Suk5gaMPNFtkILC1kzeV9xaL1PGrIMHdr4QJxcIY5s8jVLEFL0Bq4Kd6j 3mLm4PRWUVQdw== From: Pratyush Yadav To: Chenghao Duan Cc: pasha.tatashin@soleen.com, rppt@kernel.org, pratyush@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jianghaoran@kylinos.cn Subject: Re: [PATCH v3 7/7] mm/memfd_luo: fix integer overflow in memfd_luo_preserve_folios In-Reply-To: <20260326084727.118437-8-duanchenghao@kylinos.cn> (Chenghao Duan's message of "Thu, 26 Mar 2026 16:47:27 +0800") References: <20260326084727.118437-1-duanchenghao@kylinos.cn> <20260326084727.118437-8-duanchenghao@kylinos.cn> Date: Thu, 02 Apr 2026 12:06:58 +0000 Message-ID: <2vxzv7e9ftwd.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Thu, Mar 26 2026, Chenghao Duan wrote: > In memfd_luo_preserve_folios(), two variables had types that could cause > silent data loss with large files: > > 1. 'size' was declared as 'long', truncating the 64-bit result of > i_size_read(). On 32-bit systems a 4GB file would be truncated to 0, > causing the function to return early and discard all data. As Pasha said, KHO and LUO are not expected to run on 32-bit systems. Plus, since i_size_read() returns loff_t, why use u64 when you can just match the type and just use loff_t (which on 64-bit is long anyway)? I don't get why u64 is any better than long or loff_t. > > 2. 'max_folios' was declared as 'unsigned int', causing overflow for > sparse files larger than 4TB. For example, a 16TB+4KB file would > calculate 0x100000001 folios but truncate to 1 when assigned to > max_folios, causing memfd_pin_folios() to pin only the first folio. Using unsigned int was intentional. We pass max_folios to memfd_pin_folios(), which expects an unsigned int. So this change is pointless unless you go and update memfd_pin_folios() too. I think making memfd_pin_folios() use unsigned long for max_folios makes a lot of sense, so can you please go update that first before making this change? And when you do, please match the type of the argument to the type you use here instead of using u64. This can be a separate, independent patch series. > > Fix by changing both variables to 'u64' to match the types returned > by i_size_read() and the folio count calculations. > > This issue was identified by the AI review. > https://sashiko.dev/#/patchset/20260323110747.193569-1-duanchenghao@kylinos.cn > > Signed-off-by: Chenghao Duan [...] -- Regards, Pratyush Yadav