From nobody Mon Apr 6 13:30:32 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 049073D47BC for ; Thu, 19 Mar 2026 13:00:31 +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=1773925231; cv=none; b=K1SRmNQMiBQxuFe1tae5oGNVmgLn7QXh7VNxYHuVKKYBkpv4T4YKtfCvVH11ffzK+hu8X4kLNNrPqcHEUmyVQ9FDqsbWhGrymPRdtFKLDh7pzhLlzdnQskX4I48jBOZz3B9mU5PGN5qHhXg3YZkFQhZw7tMwbzqYo0+qwPYYfdk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773925231; c=relaxed/simple; bh=v8lQVzkXwOo8XYwemfH0T2OEyL/5prtqwnB27T50syc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GrI6kDwtUU++r5F+2a2MgJaiC83BqsgvlBqx+4iIXZTv9NXN9iwWANRFQdIamH74iCqrWEW057Cix9a8J1H9vuFx32QHZNeMGjB9YN2hLdk/+P020x7a8XQUeuhchw1uI8asaX4SwwX0grelrSVQBnRAEQ+RO+aKZlknwO/M9cU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mHFF5QM8; 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="mHFF5QM8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74475C2BCB2; Thu, 19 Mar 2026 13:00:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773925230; bh=v8lQVzkXwOo8XYwemfH0T2OEyL/5prtqwnB27T50syc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mHFF5QM8KYtYSTUl9vwuuKfFVITJcxtqGlTi62Obtb/ntJBkSFgkeXrXy4eKXorq1 56X7Hl7ESr5wFAmWaIpIImWovr77yYH/BCSq3fPGdjv9z2NOz5WNxAPOEU10ONZpWD gUHWg6DH+pv0SuY77oNzZpUZVrSa35vLxP/v4Nai+6+b8rmugbDSU8hF8EACK/URpV D99vWxvXBuAc1POpvcy+fc+HAwuiyuTOsY2zPA8RrPuVVtqF2Ah9HhY66Uzm89Giqd r3tv4ODzOkUBDkILY1T7s2Iy7ln6VjRK9QkpfDOWl4t6aEFB3t6SUQTIcQ1DQWtnu+ Gfvk8A25K/lGQ== 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 v2 4/9] mm/huge_memory: handle buggy PMD entry in zap_huge_pmd() Date: Thu, 19 Mar 2026 13:00:10 +0000 Message-ID: <1ec18767b106a1ee1ed6e33e332c3ad5531dc636.1773924928.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(). [0]:https://lore.kernel.org/all/6b3d7ad7-49e1-407a-903d-3103704160d8@lucife= r.local/ Signed-off-by: Lorenzo Stoakes (Oracle) Reviewed-by: Baolin Wang --- mm/huge_memory.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index bba1ba1f6b67..a2f87315195d 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, if (!thp_migration_supported()) WARN_ONCE(1, "Non present huge pmd without pmd migration enabled!"); + } else { + WARN_ON_ONCE(true); + spin_unlock(ptl); + return true; } if (folio_test_anon(folio)) { -- 2.53.0