From nobody Mon Apr 6 18:22:35 2026 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 37AAE3D6688 for ; Wed, 18 Mar 2026 12:26:40 +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=1773836801; cv=none; b=nza1AnSXYAK4FFq32YU0+4KCIUiIepcBn+RAawZQ4bwRMUatMgB29Ocf2TFBPbt777b1qmpBwYEmrASiTzrXUe2hHYVxhGosnl0HL31ecmYCzMZtk5leW/BXbj8td5+fKUYA47U/gOqOTSyGiMQtk3cahROt6S38Mm7Pzcm6hvY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773836801; c=relaxed/simple; bh=wlo6/KmRGeDlUQg4uZ5/ZwNJBHL6qZdYnfzLfFT0mzE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=f6XO10g1aZBQl/FFwFjUvieFwPgrxnd48/wYF7KcCippMSfxkBo5yqyoyG42sCaR43D09wNyxMhid/2y/wGF7wIQypTW9qExfYoCgCij750eT1tTNVqa5IjuJaCJFnb6Vf9auV98K9QFVDsEkihvWbbzhGhdXZNPWZD178X+dGs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HjRFv400; 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="HjRFv400" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37CFDC19421; Wed, 18 Mar 2026 12:26:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773836800; bh=wlo6/KmRGeDlUQg4uZ5/ZwNJBHL6qZdYnfzLfFT0mzE=; h=From:To:Cc:Subject:Date:From; b=HjRFv4007y/PrRV1FU6H7y2F+D0zeEEji4DUTBFRMoQltXzjT8Sf1lBJbVJc9UvZI tkp18Os4zDDMnUTg/ItfBtIqbcJgAhnEQ0rJgnczob2BzIUaSzjR3gEv9Q+ruLpPl8 9yxRM3j5la+5Zw5sxYqKOuPZb5/UZPmNAKYWcBjoLgGKzrzJgAblsD1yrQvjCIsMDt 7ESlXLv8vNCbU/f9AA6ICRk9DKdM5rIqs/ZbjaGBpvtKwl7Erw0HxopdKOFsjUna8I 80dQ/ETgezHlVDC+EgG3C9yYZbXROu3zcyCZdyZMJ4gd0a+pvJ+c+R+XvkflmzvLEM BiIAOGzx7baNw== From: "Lorenzo Stoakes (Oracle)" To: Andrew Morton Cc: David Hildenbrand , Rik van Riel , "Liam R . Howlett" , Vlastimil Babka , Harry Yoo , Jann Horn , Sasha Levin , Jiakai Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH mm-hotfixes] mm/rmap: clear vma->anon_vma on error Date: Wed, 18 Mar 2026 12:26:32 +0000 Message-ID: <20260318122632.63404-1-ljs@kernel.org> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit 542eda1a8329 ("mm/rmap: improve anon_vma_clone(), unlink_anon_vmas() comments, add asserts") alters the way errors are handled, but overlooked one important aspect of clean up. When a VMA encounters an error state in anon_vma_clone() (that is, on attempted allocation of anon_vma_chain objects), it cleans up partially established state in cleanup_partial_anon_vmas(), before returning an error. However, this occurs prior to anon_vma->num_active_vmas being incremented, and it also fails to clear the VMA's vma->anon_vma field, which remains in place. This is immediately an inconsistent state, because anon_vma->num_active_vmas is supposed to track the number of VMAs whose vma->anon_vma field references that anon_vma, and now that count is off-by-negative-1 for each VMA for which this error state has occurred. When VMAs are unlinked from this anon_vma, unlink_anon_vmas() will eventually underflow anon_vma->num_active_vmas, which will trigger a warning. This will always eventually happen, as we unlink anon_vma's at process teardown. It could also cause maybe_reuse_anon_vma() to incorrectly permit the reuse of an anon_vma which has active VMAs attached, which will lead to a persistently invalid state. The solution is to clear the VMA's anon_vma field when we clean up partial state, as the fact we are doing so indicates clearly that the VMA is not correctly integrated into the anon_vma tree and thus this field is invalid. Reported-by: Sasha Levin Closes: https://lore.kernel.org/linux-mm/20260302151547.2389070-1-sashal@ke= rnel.org/ Reported-by: Jiakai Xu Closes: https://lore.kernel.org/linux-mm/CAFb8wJvRhatRD-9DVmr5v5pixTMPEr3UK= jYBJjCd09OfH55CKg@mail.gmail.com/ Fixes: 542eda1a8329 ("mm/rmap: improve anon_vma_clone(), unlink_anon_vmas()= comments, add asserts") Signed-off-by: Lorenzo Stoakes (Oracle) Acked-by: David Hildenbrand (Arm) Acked-by: Harry Yoo Acked-by: Vlastimil Babka (SUSE) Tested-by: Jiakai Xu --- mm/rmap.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mm/rmap.c b/mm/rmap.c index 6398d7eef393..abe4712a220c 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -457,6 +457,13 @@ static void cleanup_partial_anon_vmas(struct vm_area_s= truct *vma) list_del(&avc->same_vma); anon_vma_chain_free(avc); } + + /* + * The anon_vma assigned to this VMA is no longer valid, as we were not + * able to correctly clone AVC state. Avoid inconsistent anon_vma tree + * state by resetting. + */ + vma->anon_vma =3D NULL; } /** -- 2.53.0