From nobody Mon Apr 6 18:22:50 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 63B35352927 for ; Wed, 18 Mar 2026 20:40:10 +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=1773866410; cv=none; b=fgCYNbIfXtecOLXEYwRimgwkX2dh4joXsdKzNwfEqXQWEm3LmHf76pTdAuTg6cstEidvX+2grxY3RP8GErumnQ6zBDSiodDE9C6JStzjdivnnnXUTBweY1CHK07sP4Qg7Jt861eIhBSRAyC/hF3ReQmafx2bo9lXArE9mJe+xk4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773866410; c=relaxed/simple; bh=4hGJuEdcThcMdbeM2AM1MWkN/V5ubnZTBsubak6jBD8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EpnbWtoh6PTyDclEgRgURdC4nSmi0Iuw8+6Lt2KzRKTLUy2GQwK6Clhx11xjGrTlYExk2SsVo4OakPxEHXuqpyyzVSUsGoOyuOmwAUpRbj1BifDf7yfql5Z8aOhIqtkQmYIsRSP+oAIJwWrTmiuISZDvfuyowFVvDJLTtdr5biM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A+LWPAJd; 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="A+LWPAJd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99554C2BC9E; Wed, 18 Mar 2026 20:40:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773866410; bh=4hGJuEdcThcMdbeM2AM1MWkN/V5ubnZTBsubak6jBD8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A+LWPAJdQaFkpuzW67ZvVhCebOVm8I33QNmUh9lnf2px0US1OI/uyMqp2yEy7cLdL QJwBo24QvR4hvDHKYSKAs0WUOCZwUJg4DAzHUE9pbjk4TnSEJULI+p8807T2xRdtbG +fCum19lJQpsThRLuu8Jt8+67nzQ8IWZbzby8E+AvSavNf8mSthpV0mlUVzZIqrsyW GegAnY1LCd5nmt2Qcxd2lhney36z0ywkzYaKejcQGyaCVT37FiSwPuO90aeLZTNclQ lid7oh1gBOTesI8cEPb2SXJqT1PAeCzUefKPghOKJRSSCZ2xKMOc9TKaEnV2ebWyIq fuSWFxidRtemg== From: "Lorenzo Stoakes (Oracle)" To: Andrew Morton Cc: David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH 4/8] mm/huge_memory: handle buggy PMD entry in zap_huge_pmd() Date: Wed, 18 Mar 2026 20:39:26 +0000 Message-ID: <8ffa393ad86b9b0ecd9b001ca88706ce2f9fe003.1773865827.git.ljs@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: 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" A recent bug I analysed [0] managed to, through a bug in the userfaultfd implementation, reach an invalid point in the zap_huge_pmd() code where the PMD was none of: - A non-DAX, PFN or mixed map. - The huge zero folio - A present PMD entry - A softleaf entry The code at this point calls folio_test_anon() on a known-NULL folio. Having logic like this explicitly NULL dereference in the code is hard to understand, and makes debugging potentially more difficult. Add an else branch to handle this case and WARN() and exit indicating failure. [0]:https://lore.kernel.org/all/6b3d7ad7-49e1-407a-903d-3103704160d8@lucife= r.local/ Signed-off-by: Lorenzo Stoakes (Oracle) --- mm/huge_memory.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index bba1ba1f6b67..8e6b7ba11448 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2478,6 +2478,10 @@ bool zap_huge_pmd(struct mmu_gather *tlb, struct vm_= area_struct *vma, =20 if (!thp_migration_supported()) WARN_ONCE(1, "Non present huge pmd without pmd migration enabled!"); + } else { + WARN_ON_ONCE(true); + spin_unlock(ptl); + return false; } =20 if (folio_test_anon(folio)) { --=20 2.53.0