From nobody Sun Feb 8 05:29:27 2026 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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 1E69C2C234C for ; Tue, 3 Feb 2026 02:09:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770084564; cv=none; b=gMYF69gB2ENR5crGgVm9WmDHazLQ4v69mqxtYPdM+nbdmDQoN1muTWG33077/OWYi/59ymDBhWBGu+agYCqlBquvlbSotLrmPMOOZ5wyt0NyCeQGYlOElRtjk+MJ/X7J84TpYXCqMxrd2qbHMOO+vK8Z2/kTbjMdIVB+fIXna30= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770084564; c=relaxed/simple; bh=ypMYOOumJWM4wC5+SVLY8/RCJmTGOmMXqKL4Fpcmjww=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=epaMefjaVY0muKPTk6iw80ruJAu4ihm7RggcwHuTv43nfraron1Ymh8b4Z6KrjPuYAg//E2FRVqCjH12mgGbgtTeCXHbyt2n0K7DQLlmZFEREig0Vu3SeS1ZWTwueRzu17C3MoFxuJSoNz3n+5gcMR/c5fcYSIocV6ZHyJcM33A= 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=cnkjjblp; arc=none smtp.client-ip=209.85.214.181 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="cnkjjblp" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2a8a7269547so49445345ad.0 for ; Mon, 02 Feb 2026 18:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770084562; x=1770689362; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=g2VTRusWSqFGE8R7XPvl8IYHFzaZordoFa2VsjIg2LQ=; b=cnkjjblpj1FwcEMybPbDWvHtjkxGnCXCC6ygEGl+9TkMOY/noexQk9TbQjGBncGt1s /so2ENsHG4Q+f2LvSJ0/r+cRqN8g7lxS2mo+67EuDV4P51fq3bkKieJWnbN1tB3fIqwb wVXcPSgw10mRqdEerp5bsVN5ap0irXtmT+cTbjuXEeOuErf7GVu2snu5vajIeD3oI4yv HhPK79No7y4/OYwfZMArkLXNXRxX/g3+rv7RF5uSnpwsURYsqAmHGpJXqol65bTv3X17 EhBnhS6rrJvl3J6Lnh5vOY/n+MHyWUxdPj2tkZxGrsKQiCzEqgWdmClyq1hcpB7k7V0J Hk+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770084562; x=1770689362; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=g2VTRusWSqFGE8R7XPvl8IYHFzaZordoFa2VsjIg2LQ=; b=cDGQleUw7tQOu2RdTGFvsgIu2LwNfGAZxfBnyHRq11+KsRirhESdCdRYO3B8Ghuf+w 8u3mmqU2sIHVbwd/Jl7Lbo/PwRFxLZ0jnOdiRYG9tsEQWeoccMby9wfebuk+ThnvfHw3 F0j2DRtaJ4m1emJVauH1qOCMaKCJWpDmolhnhJN1HZHUVYfSj9x+7bB3O1z7kRNotQwc LEx8Hp4FYw1fURPKTWWQa7nQn0IiaWr/3JTKjRmrogzOh84EM7CFtSD9K9GS4c/NKafL 4aIWB+hs/F//my7Y2TD3G8vGOsf1pmCR9/wTuKH5YY58DhTHPKSy+n/oeL0Bo6VGN7ne kg5A== X-Forwarded-Encrypted: i=1; AJvYcCVzlLPDmm34JaInl7862JKbPXjEZKrBbos88ZrU+dC1mt+mFgmqQwZv8K1NO6lVzVjbfeH0lUabL2GewVg=@vger.kernel.org X-Gm-Message-State: AOJu0YxWKYghNZaDLl+ml9a5nSaCsvyNWEuRs8jaCV5vP0Ij0D2gicKr ALhD1PQmydvjroQaQHaHA3sFCcJBjeddwT1pcXKGkASY+Xxdxat56nxq X-Gm-Gg: AZuq6aK1t8uf/MfqFzYKjSk5Tv/CncS3uKJ09yF2rNQCmebVEwzWR3H0ya9QWV7Clif 3bATH6+6voImObQzxgrS8MTPeO4OfWKyE1cwrdd7fTEGIX2X5MuzGrpQqz5JrSAHDGMqBSfHpzs pAD83Dzn/4ll3hSvT7sREud/mkQwirJcT8KC9YLmi4DPn6kdpT7yzQFO2f6FxQYzY9PMrF0Aleo 7V2Qq4ddq4Kusa9fZu3rC6POqKjCq/QErcYSfvPjK35daCNydJPE5IqPL8N9POOggjxFijOKq4p Q0zOcBFLJICpJSNk7XNkQdO2rLMDAuZJdt1nRhU9p4t0et2c6MpgCAd8W9ypRGTXTRYu1vlWuop ZMhx2VxpNvSNEPCwmykKvvk5188SnW7NaY0VJbZF10XYdSEBIurkIpulxNFtuERIsB9dMOhXM1B 7l1ieVEWNVSsVxJiFHesTw+1aaaJ2R4W0dFa2YgltxhEGcmwku/kMoI3P/Bs6jfv89j+I= X-Received: by 2002:a17:903:3d54:b0:2a2:bff6:42f5 with SMTP id d9443c01a7336-2a8d959aa61mr78235515ad.8.1770084562152; Mon, 02 Feb 2026 18:09:22 -0800 (PST) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:389d:210f:e92c:6af6:77e9]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a88b4173ccsm160333195ad.34.2026.02.02.18.09.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 18:09:21 -0800 (PST) From: Deepanshu Kartikey To: pbonzini@redhat.com Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com, Deepanshu Kartikey Subject: [PATCH] KVM: guest_memfd: Reject large folios until support is implemented Date: Tue, 3 Feb 2026 07:39:13 +0530 Message-ID: <20260203020913.100838-1-kartikey406@gmail.com> X-Mailer: git-send-email 2.43.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" Large folios are not yet supported in guest_memfd (see TODO comment in kvm_gmem_get_folio()), but can still be allocated if userspace uses madvise(MADV_HUGEPAGE), which overrides the folio order restrictions set by mapping_set_folio_order_range(). When a large folio is allocated, it triggers WARN_ON_ONCE() at line 416 in kvm_gmem_fault_user_mapping(), causing a kernel panic if panic_on_warn is enabled. Add mapping_set_folio_order_range(0, 0) as defense in depth, and actively check for large folios in kvm_gmem_get_folio() on both the fast-path (existing folio) and slow-path (newly created folio). If a large folio is found, unlock it, drop the reference, and return -E2BIG to prevent the WARNING from triggering. This avoids kernel panics when panic_on_warn is enabled. Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D33a04338019ac7e43a44 Fixes: b85524314a3d ("KVM: guest_memfd: delay kvm_gmem_prepare_folio() unti= l the memory is passed to the guest") Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey --- virt/kvm/guest_memfd.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index fdaea3422c30..ee5bcf238f98 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -143,13 +143,29 @@ static struct folio *kvm_gmem_get_folio(struct inode = *inode, pgoff_t index) folio =3D __filemap_get_folio(inode->i_mapping, index, FGP_LOCK | FGP_ACCESSED, 0); if (!IS_ERR(folio)) - return folio; + goto check_folio; =20 policy =3D mpol_shared_policy_lookup(&GMEM_I(inode)->policy, index); folio =3D __filemap_get_folio_mpol(inode->i_mapping, index, FGP_LOCK | FGP_ACCESSED | FGP_CREAT, mapping_gfp_mask(inode->i_mapping), policy); mpol_cond_put(policy); + if (IS_ERR(folio)) + return folio; +check_folio: + /* + * Large folios are not supported yet. This can still happen + * despite mapping_set_folio_order_range() if userspace uses + * madvise(MADV_HUGEPAGE) which can override the folio order + * restrictions. Reject the large folio and remove it from + * the page cache so the next fault can allocate a order-0 + * page instead. + */ + if (folio_test_large(folio)) { + folio_unlock(folio); + folio_put(folio); + return ERR_PTR(-E2BIG); + } =20 return folio; } @@ -596,6 +612,7 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t si= ze, u64 flags) inode->i_mode |=3D S_IFREG; inode->i_size =3D size; mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER); + mapping_set_folio_order_range(inode->i_mapping, 0, 0); mapping_set_inaccessible(inode->i_mapping); /* Unmovable mappings are supposed to be marked unevictable as well. */ WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping)); --=20 2.43.0