From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794064562; b=VJBps1poTsOZZxfZsCHHZEhmF7NHQKfn0CMxnvbkvml44ghWKYQ4zVVuwspXuf6xQhag iiQYkg6Sil34XWxQ95wARmqETCce761UYp393xrjObTvkVRa83/pmy97Hb3DYscUEasWS AO9Y4fqVNXr9cWmJ0uHdAA7jW3i7Q6rVpxZZqr9yekWYGfWjPD3rEpKsxPhtqbY4ZNu6/ 9aqgi4wLykv69qLD88QoB+10CddkdBj54AQe4drSxjSDlK1w+aWkGjESMp323k0CzDY9v c0YVc2WNqgCNtVvo6uKBjfJ6GyKSAlBAq7wJcvagdHy8R7nQ6EZRLYsNYvaWghR987Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794064562; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=6EfnLIUiJHyuZ8GpbJ1pme49ALEqapsEKv881XG0v24=; b=TzNOAYI6sfyfb4ToDOh9ffYNACXjEFwf9j3v5JiXbo5fxvKUvVRN0YcVP1Lx1ZucYTmo 9kFbq7FFtZHH6Cl5mCOQji5zFsWgitKAifUYB0n+nUvVcEmW3DiG4Yp5m0TDtupLN9hxM C2Jq9A4jq9GmeDpBeXUFj5dJbNsfCHrtDLn5g1BGZLThMFqyO9hTArr2AYHtXbKtrE7Ky UV1enM7gy4Y1Tl9Cbg3Fw4oSUNH01xRK1DNwaF/TyjBmwk0WZWux5tfBUgmctfd4jt3Ef 3+X9aW4xlzAXbXTm0UwhnDNcwBoFTfEpHtjC/+O5ecqLqfk66N8WJ58D3T6q8FLwZmQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=HcVL6Veo; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78C5A606A335; Sat, 7 Nov 2026 15:16:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=HcVL6Veo Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D4511F0089F; Sat, 7 Nov 2026 15:16:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794064562; bh=6EfnLIUiJHyuZ8GpbJ1pme49ALEqapsEKv881XG0v24=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HcVL6VeoMptHxuFwBhNO7WN9jEN4tlwWYa8ki4jRfa04av4mNbnvf8bvcEgthadFL 5grXGxPapduRS6veqePBqKObBtzeD6GQkFlnbO7xtPd6bD7vVfSwvrCz1psvuEr5X2 IPNTBF7Um9NTzwX352UP8I90u+Yjjmb39HbE0Bnw= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Barry Song , Johannes Weiner , Ridong Chen , Andrew Morton , Axel Rasmussen , Chris Down , David Hildenbrand , Kairui Song , Lorenzo Stoakes , Michal Hocko , Muchun Song , Roman Gushchin , Shakeel Butt , Tejun Heo , Wei Xu , Yuanchu Xie , Yu Zhao , Sasha Levin Subject: [PATCH 7.3 0582/1257] mm/page_counter: avoid integer overflow in effective_protection() Date: Sat, 7 Nov 2026 08:47:58 -0500 Message-ID: <20261107134955.426774605@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261107134939.434104957@linuxfoundation.org> References: <20261107134939.434104957@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ridong Chen [ Upstream commit 7809ce47b05671e1fa6d74bead892d6ad6c1403b ] Patch series "mm/mglru: fix ineffective memory protection for non-kswapd reclaim", v4. For MGLRU, memory.min/low is not honored during non-kswapd global reclaim (global direct reclaim and root-level memory.reclaim), because these paths shrink memcgs using stale protection (emin/elow). Patch 2 is the actual fix. Patch 1 is a prerequisite: an integer overflow in effective_protection(), spotted by the sashiko review tool, which patch 2's new caller would also be exposed to. This patch (of 2): effective_protection() scales a parent's protection by a ratio of page counts, e.g. for recursive protection: (parent_effective - siblings_protected) * (usage - protected) / (parent_usage - siblings_protected) The multiply is done at unsigned long width before dividing. On systems with >= 16TB RAM the product can exceed 2^64 and wrap, giving a bogus protection value and silently breaking memory.min/low enforcement. Use mul_u64_u64_div_u64() to multiply in a 128-bit intermediate. Because usage and parent_usage are not read atomically (a child is charged before its parent), usage - protected can briefly exceed the divisor, making the quotient overflow 64 bits and trap (#DE on x86). Cap it so the ratio stays <= 1. Reported by the sashiko review tool [1]. Link: https://lore.kernel.org/20260907025445.1836238-1-ridong.chen@linux.dev Link: https://lore.kernel.org/20260907025445.1836238-2-ridong.chen@linux.dev Link: https://sashiko.dev/#/patchset/20260826133054.88529-1-ridong.chen@linux.dev?part=1 [1] Fixes: bc50bcc6e00b ("mm: memcontrol: clean up and document effective low/min calculations") Fixes: 8a931f801340 ("mm: memcontrol: recursive memory.low protection") Reviewed-by: Barry Song Reviewed-by: Johannes Weiner Signed-off-by: Ridong Chen Signed-off-by: Andrew Morton Assisted-by: Claude:claude-opus-4-8 Cc: Axel Rasmussen Cc: Chris Down Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tejun Heo Cc: Wei Xu Cc: Yuanchu Xie Cc: Yu Zhao Cc: Signed-off-by: Sasha Levin --- mm/page_counter.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/mm/page_counter.c b/mm/page_counter.c index 661e0f2a5127a..ea0d1646cff85 100644 --- a/mm/page_counter.c +++ b/mm/page_counter.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -356,7 +357,8 @@ static unsigned long effective_protection(unsigned long usage, * otherwise get a smaller chunk than what they claimed. */ if (siblings_protected > parent_effective) - return protected * parent_effective / siblings_protected; + return mul_u64_u64_div_u64(protected, parent_effective, + siblings_protected); /* * Ok, utilized protection of all children is within what the @@ -397,13 +399,20 @@ static unsigned long effective_protection(unsigned long usage, if (parent_effective > siblings_protected && parent_usage > siblings_protected && usage > protected) { - unsigned long unclaimed; + unsigned long parent_unclaimed, parent_unprotected, unprotected; - unclaimed = parent_effective - siblings_protected; - unclaimed *= usage - protected; - unclaimed /= parent_usage - siblings_protected; + parent_unclaimed = parent_effective - siblings_protected; + parent_unprotected = parent_usage - siblings_protected; - ep += unclaimed; + /* + * The usages aren't read atomically, so a child can transiently + * appear to use more than its parent, making the ratio exceed 1 + * and the quotient overflow 64 bits (#DE on x86). Cap it. + */ + unprotected = min(usage - protected, parent_unprotected); + + ep += mul_u64_u64_div_u64(parent_unclaimed, unprotected, + parent_unprotected); } return ep; -- 2.53.0