From nobody Sun Feb 8 05:08:15 2026 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 626FC33AD81 for ; Sat, 7 Feb 2026 17:37:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770485852; cv=none; b=DbkfsODRVT/lEaRnpo16UhRe++CIL6uEyQ+VuepWQ4LORD5mfp2lCQt7p/KsVADDQwulprKqHw5dwaI4qJIKqwz9uaapUSScQNhdaujNndRxl0Iwo4X8Z6oPOUmjgvHDcqye9rSfgjriVOVhxGIsyuux/F5mjtd4wtysoUwmhWQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770485852; c=relaxed/simple; bh=E4fISVo2NO2WKZ/cPp0LpcDWkQPAsw8bdND+t6VEag0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iO4sJ1J7znOnSRavPE71oBs6MH5C4kITEJOZraa/CU3CUHOpyLErEzkFqRDKulHVxoqqKEYsVRIuUayu5MaUHztxt4yuIgxVeMiHViKHBvef2ISKP6SBOqX+k1OnBOmkLneznW90sCYa5J2w+tMb86wdj5PDD9L0qgx9zIrAhIA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=V9L1q5I5; arc=none smtp.client-ip=209.85.167.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="V9L1q5I5" Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-59e4a04f054so630607e87.3 for ; Sat, 07 Feb 2026 09:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770485850; x=1771090650; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=OBcixq1sa+YFWzLNdSovpimwkwmojM9gmgxcC+Ozzp4=; b=V9L1q5I54faY3hJl4daFHkvTZzzJcyHx6Je6OAUA6USikr5WltVZGdMkQmW57bRhOR dCfzU7HQPnx4LmxHc1O9F/Flnzsh0BjR/ANw/mnAoA/PjS90+LNdVbobmYSjfEwha8/4 +ScXFrbsOaiMtF8lyK458turwLxyxIQrVXf9oFiM94FQSTSSbAwNP9EmNHGOckZzISFq MfyxgBT0PZp3zNkZKeXf+1Thi1lEQskyi0X/hehhxMI3hl2RMtPBBMOa+1tSastRLiUd zK2eT2C+1kVqTqlDJHO4KrUNAbXAwgsKWhogB+ztiXZQV5Op+ferpvhsANwsQdOwJIBI Q1cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770485850; x=1771090650; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=OBcixq1sa+YFWzLNdSovpimwkwmojM9gmgxcC+Ozzp4=; b=VagnRcGgxvdxsWunyM+YzLKjBGb3JWLOWsJR/0o0xxENm93mHoF1enib6IXa6ADCUm KU/N4pIvpxcI4w6S3cmAy1eBwKnAIMFLo7N4fI+u+yHEcvCTpxb4N+X9VvVVfKGyS7hO Hii3xRgcLrdD+ZkO+mwIrp+irvCxZhSsgHwiDOUR/qUNbpGN0a6zrar04yV25Zf6BtRu GXFvV1OHet+efRdp966FRxHoP1/xlg6gcAv901pH2pta47wloiaTTHmxP1cfH45jgzXx NemcsANLEH0gL4n0ZjrE7rvgOph22FgXGFTUscnAVF23AVKrOC8+FM1vOzMgdGKhHF+M Vwmw== X-Forwarded-Encrypted: i=1; AJvYcCUr4KiwdiwZhaLXqWn3BOUQGIa79G7j/hBmc/aB8B7eAgaLLOA4ZE/jt5pqgLDimNzB0Tmebcc22Z3tmao=@vger.kernel.org X-Gm-Message-State: AOJu0YzB2kIRkEoIhxr/JictVsr0Na48Lb/Buy39Lkqn9WMmEdPuTIJd fyVtkhnbHUixmz2hFb9EqXc8rF9mVMyhu65LRTi3ob7RlBr/iap1NG3R X-Gm-Gg: AZuq6aI3JStuHDR2Hc5tsb/rRFCCdJaf6kyCIHOYK2t5RTQ8/lqifLSmBLyfi4QE9yb 1CXeWMOAUjmu/REgP4EACWeSYN2wamEku0EZgYUvv81AArfXQMMNm8xTc5XYEy5lApKhpzxN29X L5Dm7+o2dtrEBDSOd7w69csc4Vu14eyuZgkvHXpbt/0UYxa15fusGJl3QKx5xEgWIN7f0B0AG7r gMMyIaK2uki/sW3X7qp6/wkXseYtGpGQZBjzzZDsx5ZACKiKw6k7aADa7rIFxHiX47nc6Wlu2x1 eBqbowzhB3EF9x43SYhkMVC8Rs+as+340LnIQIKfjR1eoqu3Tv279J2SKwCN4BoUsfljTWT9l5J tLw2+sbUiiPvdkt0E9ccDUSefFwTy97nDA25TkS8Rt63VxFb6rUNwOP1fF4gAIuo236scJCm9Ml E7OUZTdambHSO+phzvX6ACUw== X-Received: by 2002:a05:6512:3341:b0:59e:a2d:daa1 with SMTP id 2adb3069b0e04-59e450438bemr1745187e87.5.1770485850237; Sat, 07 Feb 2026 09:37:30 -0800 (PST) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-59e44cfd475sm1405628e87.29.2026.02.07.09.37.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Feb 2026 09:37:28 -0800 (PST) From: Mikhail Gavrilov To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, npiggin@gmail.com, linux-kernel@vger.kernel.org, kasong@tencent.com, hughd@google.com, chrisl@kernel.org, ryncsn@gmail.com, stable@vger.kernel.org, david@kernel.org, willy@infradead.org, Mikhail Gavrilov Subject: [PATCH v3] mm/page_alloc: clear page->private in free_pages_prepare() Date: Sat, 7 Feb 2026 22:36:14 +0500 Message-ID: <20260207173615.146159-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <209207FE-D3A9-4BE2-8DA7-9BE38A19F387@nvidia.com> References: <209207FE-D3A9-4BE2-8DA7-9BE38A19F387@nvidia.com> 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" Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private =3D=3D 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000= 000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use. Fixes: 3b8000ae185c ("mm/vmalloc: huge vmalloc backing pages should be spli= t rather than compound") Cc: stable@vger.kernel.org Suggested-by: Zi Yan Acked-by: Zi Yan Signed-off-by: Mikhail Gavrilov --- mm/page_alloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index cbf758e27aa2..24ac34199f95 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1430,6 +1430,7 @@ __always_inline bool free_pages_prepare(struct page *= page, =20 page_cpupid_reset_last(page); page->flags.f &=3D ~PAGE_FLAGS_CHECK_AT_PREP; + page->private =3D 0; reset_page_owner(page, order); page_table_check_free(page, order); pgalloc_tag_sub(page, 1 << order); --=20 2.53.0