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 91ECC34753F for ; Tue, 21 Apr 2026 07:18:52 +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=1776755932; cv=none; b=S3Cvm7we8rUPGa8A3hKip2PqMbma1Z7HybzBVe699cgZF8G0VNhWs0AQRlYgmgqO8SfWMBCANZlXFfTjIonQsYfTTzsBPnYRTM6JwClgdKMCbL9jActIyOiXvtRCLsLlTak/JhAolr6FxkUpGUM4ylrkWxFsewHpVYM+nXc1lWI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776755932; c=relaxed/simple; bh=S6ukYIEa7PkKZt0aeWQsFUMV2dD52iDECI8Kl9MrcyU=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=Lutu4Wg+wLqKM6NSb/Y4iBp2zG5Rm3k3hi+Up/AHqpqc9X23GI0M6FI1fI5BzDMMMyPSU/QFI92Sw+H8ZrgWxi4MxAXYmlobbSPm9hfOgu1R/T3sQXPReSaXD2UeHKGYrfqkZez76rqkfVgrX5PckWMHXiW8FmV++yEbn8eKCDo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hULAVxHR; 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="hULAVxHR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 615CFC2BCB5; Tue, 21 Apr 2026 07:18:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776755932; bh=S6ukYIEa7PkKZt0aeWQsFUMV2dD52iDECI8Kl9MrcyU=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=hULAVxHRy4aIDb5Ad7g3vKoJlGRKEvPgaMlRs457W+tQEkuJcbi5XXwXWPbeBd6GL fpll86KYG4FB9e2yC1vHxBK2sbhpXpcp0fyW+0L/+yMUhQaNpEF6zCBM83JSvmo/Cv WVddOy7TbqdGj1JRtsmUTwwz8ZIqulDYWgKNa8cSrV8bKfragjFV0aBSt5J3nbN6cy 60z8JQv6Mug2uVGwquPf/LNSJvg8dgDE/nP7QgdRQtc/JBlbib5wiJK6Rj9z6AfwrV rEvqRRchy0smmcarGlNUj6g3WIhZiUwMvdqZ3TIkteEW29chcD5/Qd8GN/lsJ4SCdD 7FYcL1oiC4oFg== Message-ID: <56b30a7d-05a4-4b79-a743-0ed4a4b510c0@kernel.org> Date: Tue, 21 Apr 2026 15:18:49 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, LKML , oliver.yang@linux.alibaba.com Subject: Re: [PATCH] erofs: fix offset truncation when shifting pgoff on 32-bit platforms To: Gao Xiang , linux-erofs@lists.ozlabs.org References: <20260420034612.1899973-1-hsiangkao@linux.alibaba.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260420034612.1899973-1-hsiangkao@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/20/2026 11:46 AM, Gao Xiang wrote: > On 32-bit platforms, pgoff_t is 32 bits wide, so left-shifting > large arbitrary pgoff_t values by PAGE_SHIFT performs 32-bit arithmetic > and silently truncates the result for pages beyond the 4 GiB boundary. > > Cast the page index to loff_t before shifting to produce a correct > 64-bit byte offset. > > Fixes: 386292919c25 ("erofs: introduce readmore decompression strategy") > Fixes: 307210c262a2 ("erofs: verify metadata accesses for file-backed mounts") > Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Thanks,