From nobody Thu Apr 9 13:30:34 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 4CF822AD03 for ; Mon, 2 Mar 2026 15:15:58 +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=1772464558; cv=none; b=IuYri2dwTf8kaA69SbgotSFy9lLSZevs1hgNp1al1k4j26Dqx8nrQcsxUyGzPmbSuphlyDlLBw63mkmyPyl3GR0fyqUogT8FaprOXdqA9QQfYafzSntHrovUKjVOvsmVVT5XxbxycnlGvl/RD+JbohReb6O7U5Vv0DVC1ATngjw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772464558; c=relaxed/simple; bh=3+JOWRGzFxXHP0onO2qJa4UBvnD923gCutsUvkicEeE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TB5QKCBEkIM7dyf4FwTsCUz3Av8JvdU7CHO/W1u67H9Yq4Gs3WFknAD/aNIEtfyrwKxZpll/A2eD7oB8qXhnXKM+GTnwvRmmBm7uzTroClb4hPj4vgdn+0/msvTwRzA7Fw9Y/TwxYyQwTe2EwnXg+WE/FLpzLTxXlHxjHwaSu5w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UuShyuh/; 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="UuShyuh/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED769C19423; Mon, 2 Mar 2026 15:15:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772464557; bh=3+JOWRGzFxXHP0onO2qJa4UBvnD923gCutsUvkicEeE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UuShyuh/ZlJhCyQkAT1EPymurTXjiIysMRaTjzwDcOxWociXs+dpYDhw0peM3Dysz uEYoKK0FO4GH9fLb3l0EkO0ZHj0SjUrZSdBnjHyBaraORA31jbBkSawjcnBykVb23q 8RZHTeYPuUcA+HIhPCUt6q8dg2en+j/mWcoJF3ynGGQIQkE7v0bWJ6ECq9NkY+44L1 n15gBNY2gTSVTk+k0B1WMcMOH18NEOhzuzb8OQCueeDnYI44PjYcQgTfPRrN2GnBwR vhgd2f7rqEwXU4r/hgFOyjjPNrROq36ugiJcWIb3RsSwHzR85DI58Tl5U2HbYQNlsj hjYSrURkPJxWQ== From: Sasha Levin To: lorenzo.stoakes@oracle.com Cc: akpm@linux-foundation.org, david@kernel.org, gavinguo@igalia.com, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, sashal@kernel.org, ziy@nvidia.com Subject: [WIP] mm/vma: clear dst->anon_vma on anon_vma_clone() failure in dup_anon_vma() Date: Mon, 2 Mar 2026 10:15:47 -0500 Message-ID: <20260302151547.2389070-1-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <9e273ce7-8471-495c-a344-d9bf61cb808c@lucifer.local> References: <9e273ce7-8471-495c-a344-d9bf61cb808c@lucifer.local> 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" When dup_anon_vma() calls anon_vma_clone() and it fails with -ENOMEM, dst->anon_vma is left pointing at src->anon_vma without a corresponding num_active_vmas increment (which only happens on the success path). The internal cleanup_partial_anon_vmas() correctly frees partially- allocated AVCs but does not clear dst->anon_vma. Later, when the VMA is torn down during process exit, unlink_anon_vmas() sees a non-NULL vma->anon_vma and decrements num_active_vmas without a prior matching increment, causing an underflow. This eventually triggers: WARNING: mm/rmap.c:528 at unlink_anon_vmas+0x68e/0x900 mm/rmap.c:528 First, fault injection in the mlock2 syscall path: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 3 PID: 4261 Comm: syz.6.96 Call Trace: should_fail_ex.cold+0xd8/0x15d should_failslab+0xd4/0x150 kmem_cache_alloc_noprof+0x60/0x630 anon_vma_clone+0x2ed/0xcf0 dup_anon_vma+0x1cb/0x320 vma_modify+0x16dd/0x2230 vma_modify_flags+0x1f9/0x350 mlock_fixup+0x225/0xe10 apply_vma_lock_flags+0x249/0x360 do_mlock+0x269/0x7f0 __x64_sys_mlock2+0xc0/0x100 Followed by the WARNING on the same task during exit: WARNING: mm/rmap.c:528 at unlink_anon_vmas+0x68e/0x900 CPU: 3 PID: 4261 Comm: syz.6.96 Call Trace: free_pgtables+0x312/0x950 exit_mmap+0x487/0xa80 __mmput+0x11b/0x540 exit_mm do_exit+0x7b9/0x2c60 Fix this by clearing dst->anon_vma on clone failure, restoring the VMA to its original unfaulted state. This ensures unlink_anon_vmas() will correctly bail out early at the !active_anon_vma check. Other callers of anon_vma_clone() are unaffected: VMA_OP_SPLIT/REMAP free the dst VMA on error, and VMA_OP_FORK explicitly sets anon_vma to NULL before cloning. Fixes: 542eda1a83294 ("mm/rmap: improve anon_vma_clone(), unlink_anon_vmas(= ) comments, add asserts") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Sasha Levin --- mm/vma.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/vma.c b/mm/vma.c index be64f781a3aa7..4cf6a2a05c10a 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -629,8 +629,10 @@ static int dup_anon_vma(struct vm_area_struct *dst, vma_assert_write_locked(dst); dst->anon_vma =3D src->anon_vma; ret =3D anon_vma_clone(dst, src, VMA_OP_MERGE_UNFAULTED); - if (ret) + if (ret) { + dst->anon_vma =3D NULL; return ret; + } =20 *dup =3D dst; } --=20 2.51.0