[syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    1f97d9dcf536 Merge tag 'vfio-v6.19-rc8' of https://github...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10b3e322580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15e5ebfa580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13eef85a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/f898291c4b7b/disk-1f97d9dc.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/cac48e20323c/vmlinux-1f97d9dc.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d2e60d34b7e7/bzImage-1f97d9dc.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com

------------[ cut here ]------------
folio_test_large(folio)
WARNING: arch/x86/kvm/../../../virt/kvm/guest_memfd.c:416 at kvm_gmem_fault_user_mapping+0x4b5/0x6e0 virt/kvm/guest_memfd.c:416, CPU#1: syz.3.124/6406
Modules linked in:
CPU: 1 UID: 0 PID: 6406 Comm: syz.3.124 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026
RIP: 0010:kvm_gmem_fault_user_mapping+0x4b5/0x6e0 virt/kvm/guest_memfd.c:416
Code: 00 e9 a1 fe ff ff bd 00 04 00 00 eb d9 e8 43 b8 83 00 48 c7 c6 e0 9f 82 8b 48 89 df e8 d4 f8 ce 00 90 0f 0b e8 2c b8 83 00 90 <0f> 0b 90 48 8d 6b 34 48 89 df e8 ec f6 bb 00 be 04 00 00 00 48 89
RSP: 0018:ffffc90004ab7848 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffea00018a0000 RCX: ffffffff81834070
RDX: ffff888028b124c0 RSI: ffffffff81834334 RDI: ffff888028b124c0
RBP: ffffc90004ab79f8 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000040 R11: 0000000000000000 R12: ffffea00018a0000
R13: ffffc90004ab7a08 R14: 0000000000000040 R15: ffffea00018a0008
FS:  00007fb8562ce6c0(0000) GS:ffff8881246db000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f89fb863d58 CR3: 000000006060a000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 __do_fault+0x10d/0x550 mm/memory.c:5323
 do_read_fault mm/memory.c:5758 [inline]
 do_fault+0xaf9/0x1990 mm/memory.c:5892
 do_pte_missing mm/memory.c:4404 [inline]
 handle_pte_fault mm/memory.c:6276 [inline]
 __handle_mm_fault+0x1807/0x2b50 mm/memory.c:6414
 handle_mm_fault+0x36d/0xa20 mm/memory.c:6583
 faultin_page mm/gup.c:1126 [inline]
 __get_user_pages+0xf9c/0x34d0 mm/gup.c:1428
 populate_vma_page_range+0x267/0x3f0 mm/gup.c:1860
 __mm_populate+0x107/0x3a0 mm/gup.c:1963
 do_mlock+0x3f0/0x7f0 mm/mlock.c:653
 __do_sys_mlock mm/mlock.c:661 [inline]
 __se_sys_mlock mm/mlock.c:659 [inline]
 __x64_sys_mlock+0x59/0x80 mm/mlock.c:659
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb85539aeb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb8562ce028 EFLAGS: 00000246 ORIG_RAX: 0000000000000095
RAX: ffffffffffffffda RBX: 00007fb855615fa0 RCX: 00007fb85539aeb9
RDX: 0000000000000000 RSI: 0000000000800000 RDI: 0000200000000000
RBP: 00007fb855408c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb855616038 R14: 00007fb855615fa0 R15: 00007ffcc1750088
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Forwarded: [PATCH] KVM: guest_memfd: Restrict to order-0 folios until large folio support is implemented

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] KVM: guest_memfd: Restrict to order-0 folios until large folio support is implemented
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


The kvm_gmem_fault_user_mapping() function currently triggers a warning
when it receives large folios, as indicated by the WARN_ON_ONCE() at
line 416. The code comment in kvm_gmem_get_folio() clearly states
"TODO: Support huge pages", indicating that large folio support is not
yet implemented.

Without explicitly restricting the folio order, filemap_grab_folio() may
opportunistically allocate large folios when memory is available, causing
the warning to trigger and the page fault to fail with VM_FAULT_SIGBUS.

Fix this by explicitly setting the mapping's folio order range to (0, 0)
during inode initialization, ensuring only order-0 (single-page) folios
are allocated until proper large folio support is added.

Reproducer: mlock() on memory backed by guest_memfd with
GUEST_MEMFD_FLAG_INIT_SHARED triggers the warning when large folios
are allocated.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 virt/kvm/guest_memfd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..4dc154b4b370 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -596,6 +596,7 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	inode->i_mode |= S_IFREG;
 	inode->i_size = 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));
-- 
2.43.0

Forwarded: [PATCH] KVM: guest_memfd: Restrict to order-0 folios until large folio support is implemented

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] KVM: guest_memfd: Restrict to order-0 folios until large folio support is implemented
Author: kartikey406@gmail.com


#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


The kvm_gmem_fault_user_mapping() function currently triggers a warning
when it receives large folios, as indicated by the WARN_ON_ONCE() at
line 416. The code comment in kvm_gmem_get_folio() clearly states
"TODO: Support huge pages", indicating that large folio support is not
yet implemented.

Without explicitly restricting the folio order, filemap_grab_folio() may
opportunistically allocate large folios when memory is available, causing
the warning to trigger and the page fault to fail with VM_FAULT_SIGBUS.

Fix this by explicitly setting the mapping's folio order range to (0, 0)
during inode initialization in __kvm_gmem_create(), ensuring only order-0
(single-page) folios are allocated until proper large folio support is
added.

Reproducer: mlock() on memory backed by guest_memfd with
GUEST_MEMFD_FLAG_INIT_SHARED triggers the warning when large folios
are allocated.

Add debug logging to track folio order configuration and allocation
for further investigation.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 virt/kvm/guest_memfd.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..e513e0f735d0 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -412,7 +412,8 @@ static vm_fault_t kvm_gmem_fault_user_mapping(struct vm_fault *vmf)
 
 		return vmf_error(PTR_ERR(folio));
 	}
-
+	pr_info("KVM: fault got folio, large=%d order=%u\n",
+	folio_test_large(folio), folio_order(folio));
 	if (WARN_ON_ONCE(folio_test_large(folio))) {
 		ret = VM_FAULT_SIGBUS;
 		goto out_folio;
@@ -596,6 +597,10 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	inode->i_mode |= S_IFREG;
 	inode->i_size = size;
 	mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
+	mapping_set_folio_order_range(inode->i_mapping, 0, 0);
+	pr_info("KVM: guest_memfd created, folio_order min=%u max=%u\n",
+	mapping_min_folio_order(inode->i_mapping),
+	mapping_max_folio_order(inode->i_mapping));
 	mapping_set_inaccessible(inode->i_mapping);
 	/* Unmovable mappings are supposed to be marked unevictable as well. */
 	WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping));
-- 
2.43.0

Forwarded: [PATCH] KVM: guest_memfd: Restrict to order-0 folios until large folio support is implemented

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] KVM: guest_memfd: Restrict to order-0 folios until large folio support is implemented
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


The kvm_gmem_fault_user_mapping() function currently triggers a warning
when it receives large folios, as indicated by the WARN_ON_ONCE() at
line 416. The code comment in kvm_gmem_get_folio() clearly states
"TODO: Support huge pages", indicating that large folio support is not
yet implemented.

Without explicitly restricting the folio order, filemap_grab_folio() may
opportunistically allocate large folios when memory is available, causing
the warning to trigger and the page fault to fail with VM_FAULT_SIGBUS.

Fix this by explicitly setting the mapping's folio order range to (0, 0)
during inode initialization in __kvm_gmem_create(), ensuring only order-0
(single-page) folios are allocated until proper large folio support is
added.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 virt/kvm/guest_memfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..679814ec1874 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -596,7 +596,7 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	inode->i_mode |= S_IFREG;
 	inode->i_size = size;
 	mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
-	mapping_set_inaccessible(inode->i_mapping);
+	mapping_set_folio_order_range(inode->i_mapping, 0, 0);
 	/* Unmovable mappings are supposed to be marked unevictable as well. */
 	WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping));
 
-- 
2.43.0

Forwarded: [PATCH] KVM: guest_memfd: Restrict to order-0 folios until large folio support is implemented

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] KVM: guest_memfd: Restrict to order-0 folios until large folio support is implemented
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


The kvm_gmem_fault_user_mapping() function currently triggers a warning
when it receives large folios, as indicated by the WARN_ON_ONCE() at
line 416. The code comment in kvm_gmem_get_folio() clearly states
"TODO: Support huge pages", indicating that large folio support is not
yet implemented.

Without explicitly restricting the folio order, filemap_grab_folio() may
opportunistically allocate large folios when memory is available, causing
the warning to trigger and the page fault to fail with VM_FAULT_SIGBUS.

Fix this by explicitly setting the mapping's folio order range to (0, 0)
during inode initialization in __kvm_gmem_create(), ensuring only order-0
(single-page) folios are allocated until proper large folio support is
added.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 virt/kvm/guest_memfd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..4dc154b4b370 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -596,6 +596,7 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	inode->i_mode |= S_IFREG;
 	inode->i_size = 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));
-- 
2.43.0

Forwarded: [PATCH] KVM: guest_memfd: Reject large folios until support is implemented

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] KVM: guest_memfd: Reject large folios until support is implemented
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

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(). If found,
remove the large folio from the page cache and return -E2BIG to
force reallocation as an order-0 page.

This prevents the WARNING from triggering and avoids kernel panics.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 virt/kvm/guest_memfd.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..60181efdc00a 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -143,13 +143,30 @@ static struct folio *kvm_gmem_get_folio(struct inode *inode, pgoff_t index)
 	folio = __filemap_get_folio(inode->i_mapping, index,
 				    FGP_LOCK | FGP_ACCESSED, 0);
 	if (!IS_ERR(folio))
-		return folio;
+		goto check_folio;
 
 	policy = mpol_shared_policy_lookup(&GMEM_I(inode)->policy, index);
 	folio = __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);
+		filemap_remove_folio(folio);
+		folio_put(folio);
+		return ERR_PTR(-E2BIG);
+	}
 
 	return folio;
 }
@@ -596,6 +613,7 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	inode->i_mode |= S_IFREG;
 	inode->i_size = 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));
-- 
2.43.0

Forwarded: [PATCH] KVM: guest_memfd: Reject large folios until support is implemented

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] KVM: guest_memfd: Reject large folios until support is implemented
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


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
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 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 = __filemap_get_folio(inode->i_mapping, index,
 				    FGP_LOCK | FGP_ACCESSED, 0);
 	if (!IS_ERR(folio))
-		return folio;
+		goto check_folio;
 
 	policy = mpol_shared_policy_lookup(&GMEM_I(inode)->policy, index);
 	folio = __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);
+	}
 
 	return folio;
 }
@@ -596,6 +612,7 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	inode->i_mode |= S_IFREG;
 	inode->i_size = 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));
-- 
2.43.0

Forwarded: [PATCH 1/2] KVM: guest_memfd: Always use order 0 when allocating for guest_memfd

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH 1/2] KVM: guest_memfd: Always use order 0 when allocating for guest_memfd
Author: ackerleytng@google.com

#syz test: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next

filemap_{grab,get}_folio() and related functions, used since the early
stages of guest_memfd have determined the order of the folio to be
allocated by looking up mapping_min_folio_order(mapping). As identified by
syzbot, MADV_HUGEPAGE can be used to set the result of
mapping_min_folio_order() to a value greater than 0, leading to the
allocation of a huge page and subsequent WARNing.

Refactor the allocation code of guest_memfd to directly use
filemap_add_folio(), specifying an order of 0.

This refactoring replaces the original functionality where FGP_LOCK and
FGP_CREAT are requested. Opportunistically drop functionality provided by
FGP_ACCESSED. guest_memfd folios don't care about accessed flags because
guest_memfd memory is unevictable and there is no storage to write back to.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
 virt/kvm/guest_memfd.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..0c58f6aa5609 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -135,23 +135,35 @@ static struct folio *kvm_gmem_get_folio(struct inode *inode, pgoff_t index)
 	/* TODO: Support huge pages. */
 	struct mempolicy *policy;
 	struct folio *folio;
+	gfp_t gfp;
+	int ret;

 	/*
 	 * Fast-path: See if folio is already present in mapping to avoid
 	 * policy_lookup.
 	 */
+repeat:
 	folio = __filemap_get_folio(inode->i_mapping, index,
 				    FGP_LOCK | FGP_ACCESSED, 0);
 	if (!IS_ERR(folio))
 		return folio;

+	gfp = mapping_gfp_mask(inode->i_mapping);
+
 	policy = mpol_shared_policy_lookup(&GMEM_I(inode)->policy, index);
-	folio = __filemap_get_folio_mpol(inode->i_mapping, index,
-					 FGP_LOCK | FGP_ACCESSED | FGP_CREAT,
-					 mapping_gfp_mask(inode->i_mapping), policy);
+	folio = filemap_alloc_folio(gfp, 0, policy);
 	mpol_cond_put(policy);
+	if (!folio)
+		return ERR_PTR(-ENOMEM);

-	return folio;
+	ret = filemap_add_folio(inode->i_mapping, folio, index, gfp);
+	if (ret)
+		folio_put(folio);
+
+	if (ret == -EEXIST)
+		goto repeat;
+
+	return ret ? ERR_PTR(ret) : folio;
 }

 static enum kvm_gfn_range_filter kvm_gmem_get_invalidate_filter(struct inode *inode)
--
2.53.0.rc2.204.g2597b5adb4-goog

[PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[Ackerley Tng]

#syz test: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next

guest_memfd VMAs don't need to be merged, especially now, since guest_memfd
only supports PAGE_SIZE folios.

Set VM_DONTEXPAND on guest_memfd VMAs.

In addition, this disables khugepaged from operating on guest_memfd folios,
which may result in unintended merging of guest_memfd folios.

Change-Id: I5867edcb66b075b54b25260afd22a198aee76df1
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
 virt/kvm/guest_memfd.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..3d4ac461c28b 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -480,6 +480,12 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma)
 		return -EINVAL;
 	}

+	/*
+	 * Disable VMA merging - guest_memfd VMAs should be
+	 * static. This also stops khugepaged from operating on
+	 * guest_memfd VMAs and folios.
+	 */
+	vm_flags_set(vma, VM_DONTEXPAND);
 	vma->vm_ops = &kvm_gmem_vm_ops;

 	return 0;
--
2.53.0.rc2.204.g2597b5adb4-goog

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com

Tested on:

commit:         0499add8 Merge tag 'kvm-x86-fixes-6.19-rc1' of https:/..
git tree:       git://git.kernel.org/pub/scm/virt/kvm/kvm.git next
console output: https://syzkaller.appspot.com/x/log.txt?x=1778a402580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=3aec2f7e1730a8eb
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=13b847fa580000

Note: testing is done by a robot and is best-effort only.

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[Ackerley Tng]

Ackerley Tng <ackerleytng@google.com> writes:

> #syz test: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next
>
> guest_memfd VMAs don't need to be merged, especially now, since guest_memfd
> only supports PAGE_SIZE folios.
>
> Set VM_DONTEXPAND on guest_memfd VMAs.
>

Local tests and syzbot agree that this fixes the issue identified. :)

I would like to look into madvise(MADV_COLLAPSE) and uprobes triggering
mapping/folio collapsing before submitting a full patch series.

David, Michael, Vishal, what do you think of the choice of setting
VM_DONTEXPAND to disable khugepaged?

+ For 4K guest_memfd, there's really nothing to expand
+ For THP and HugeTLB guest_memfd (future), we actually don't want
expansion of the VMAs.

IIUC setting VM_DONTEXPAND doesn't affect mremap() as long as the
remapping does not involve expansion.

> In addition, this disables khugepaged from operating on guest_memfd folios,
> which may result in unintended merging of guest_memfd folios.
>
> Change-Id: I5867edcb66b075b54b25260afd22a198aee76df1
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
>  virt/kvm/guest_memfd.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index fdaea3422c30..3d4ac461c28b 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -480,6 +480,12 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma)
>  		return -EINVAL;
>  	}
>
> +	/*
> +	 * Disable VMA merging - guest_memfd VMAs should be
> +	 * static. This also stops khugepaged from operating on
> +	 * guest_memfd VMAs and folios.
> +	 */
> +	vm_flags_set(vma, VM_DONTEXPAND);
>  	vma->vm_ops = &kvm_gmem_vm_ops;
>
>  	return 0;
> --
> 2.53.0.rc2.204.g2597b5adb4-goog

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[Sean Christopherson]

On Wed, Feb 04, 2026, Ackerley Tng wrote:
> Ackerley Tng <ackerleytng@google.com> writes:
> 
> > #syz test: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next
> >
> > guest_memfd VMAs don't need to be merged,

Why not?  There are benefits to merging VMAs that have nothing to do with folios.
E.g. map 1GiB of guest_memfd with 512*512 4KiB VMAs, and then it becomes quite
desirable to merge all of those VMAs into one.

Creating _hugepages_ doesn't add value, but that's not the same things as merging
VMAs.

> > especially now, since guest_memfd only supports PAGE_SIZE folios.
> >
> > Set VM_DONTEXPAND on guest_memfd VMAs.
>
> Local tests and syzbot agree that this fixes the issue identified. :)
> 
> I would like to look into madvise(MADV_COLLAPSE) and uprobes triggering
> mapping/folio collapsing before submitting a full patch series.
> 
> David, Michael, Vishal, what do you think of the choice of setting
> VM_DONTEXPAND to disable khugepaged?

I'm not one of the above, but for me it feels very much like treating a symptom
and not fixing the underlying cause.

It seems like what KVM should do is not block one path that triggers hugepage
processing, but instead flat out disallow creating hugepages.  Unfortunately,
AFAICT, there's no existing way to prevent madvise() from clearing VM_NOHUGEPAGE,
so we can't simply force that flag.

I'd prefer not to special case guest_memfd, a la devdax, but I also want to address
this head-on, not by removing a tangentially related trigger.

> + For 4K guest_memfd, there's really nothing to expand
> + For THP and HugeTLB guest_memfd (future), we actually don't want
> expansion of the VMAs.
> 
> IIUC setting VM_DONTEXPAND doesn't affect mremap() as long as the
> remapping does not involve expansion.
> 
> > In addition, this disables khugepaged from operating on guest_memfd folios,
> > which may result in unintended merging of guest_memfd folios.
> >
> > Change-Id: I5867edcb66b075b54b25260afd22a198aee76df1
> > Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> > ---
> >  virt/kvm/guest_memfd.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> > index fdaea3422c30..3d4ac461c28b 100644
> > --- a/virt/kvm/guest_memfd.c
> > +++ b/virt/kvm/guest_memfd.c
> > @@ -480,6 +480,12 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma)
> >  		return -EINVAL;
> >  	}
> >
> > +	/*
> > +	 * Disable VMA merging - guest_memfd VMAs should be
> > +	 * static. This also stops khugepaged from operating on
> > +	 * guest_memfd VMAs and folios.
> > +	 */
> > +	vm_flags_set(vma, VM_DONTEXPAND);
> >  	vma->vm_ops = &kvm_gmem_vm_ops;
> >
> >  	return 0;
> > --
> > 2.53.0.rc2.204.g2597b5adb4-goog

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[David Hildenbrand (arm)]

On 2/4/26 22:37, Sean Christopherson wrote:
> On Wed, Feb 04, 2026, Ackerley Tng wrote:
>> Ackerley Tng <ackerleytng@google.com> writes:
>>
>>> #syz test: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next
>>>
>>> guest_memfd VMAs don't need to be merged,
> 
> Why not?  There are benefits to merging VMAs that have nothing to do with folios.
> E.g. map 1GiB of guest_memfd with 512*512 4KiB VMAs, and then it becomes quite
> desirable to merge all of those VMAs into one.
> 
> Creating _hugepages_ doesn't add value, but that's not the same things as merging
> VMAs.
> 
>>> especially now, since guest_memfd only supports PAGE_SIZE folios.
>>>
>>> Set VM_DONTEXPAND on guest_memfd VMAs.
>>
>> Local tests and syzbot agree that this fixes the issue identified. :)
>>
>> I would like to look into madvise(MADV_COLLAPSE) and uprobes triggering
>> mapping/folio collapsing before submitting a full patch series.
>>
>> David, Michael, Vishal, what do you think of the choice of setting
>> VM_DONTEXPAND to disable khugepaged?
> 
> I'm not one of the above, but for me it feels very much like treating a symptom
> and not fixing the underlying cause.

And you are spot-on :)

> 
> It seems like what KVM should do is not block one path that triggers hugepage
> processing, but instead flat out disallow creating hugepages.  Unfortunately,
> AFAICT, there's no existing way to prevent madvise() from clearing VM_NOHUGEPAGE,
> so we can't simply force that flag.
> 
> I'd prefer not to special case guest_memfd, a la devdax, but I also want to address
> this head-on, not by removing a tangentially related trigger.

VM_NOHUGEPAGE also smells like the wrong thing. This is a file limitation.

!thp_vma_allowable_order() must take care of that somehow down in 
__thp_vma_allowable_orders(), by checking the file).

Likely the file_thp_enabled() check is the culprit with 
CONFIG_READ_ONLY_THP_FOR_FS?

Maybe we need a flag to say "even not CONFIG_READ_ONLY_THP_FOR_FS".

I wonder how we handle that for secretmem. Too late for me, going to bed :)

-- 
Cheers,

David

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[Ackerley Tng]

"David Hildenbrand (arm)" <david@kernel.org> writes:

> On 2/4/26 22:37, Sean Christopherson wrote:
>> On Wed, Feb 04, 2026, Ackerley Tng wrote:
>>> Ackerley Tng <ackerleytng@google.com> writes:
>>>
>>>> #syz test: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next
>>>>
>>>> guest_memfd VMAs don't need to be merged,
>>
>> Why not?  There are benefits to merging VMAs that have nothing to do with folios.
>> E.g. map 1GiB of guest_memfd with 512*512 4KiB VMAs, and then it becomes quite
>> desirable to merge all of those VMAs into one.
>>

I didn't realise VM_DONTEXPAND's no expansion policy extends to the case
where adjacent VMAs with the same flags, etc automatically merge. Since
VM_DONTEXPAND blocks this kind of expansion, I agree VM_DONTEXPAND is
not great.

>> Creating _hugepages_ doesn't add value, but that's not the same things as merging
>> VMAs.
>>
>>>> especially now, since guest_memfd only supports PAGE_SIZE folios.
>>>>
>>>> Set VM_DONTEXPAND on guest_memfd VMAs.
>>>
>>> Local tests and syzbot agree that this fixes the issue identified. :)
>>>
>>> I would like to look into madvise(MADV_COLLAPSE) and uprobes triggering
>>> mapping/folio collapsing before submitting a full patch series.
>>>
>>> David, Michael, Vishal, what do you think of the choice of setting
>>> VM_DONTEXPAND to disable khugepaged?
>>
>> I'm not one of the above, but for me it feels very much like treating a symptom

Was going to find some solution before getting to you to save you some
time :)

>> and not fixing the underlying cause.
>
> And you are spot-on :)
>
>>
>> It seems like what KVM should do is not block one path that triggers hugepage
>> processing, but instead flat out disallow creating hugepages.  Unfortunately,

__filemap_get_folio_mpol(), which we use in kvm_gmem_get_folio(), looks
up mapping_min_folio_order() to determine what order to allocate. I
think we could lock that down to always use order 0. I tried that here
[1] but in this case khugepaged allocates new folios for guest_memfd
(and others) directly in collapse_file(), explicitly specifying
PMD_ORDER.

I took a look and wasn't able to find a central callback/ops to catch
all fs allocations.

[1] https://lore.kernel.org/all/6982553e.a00a0220.34fa92.0009.GAE@google.com/

>> AFAICT, there's no existing way to prevent madvise() from clearing VM_NOHUGEPAGE,
>> so we can't simply force that flag.
>>
>> I'd prefer not to special case guest_memfd, a la devdax, but I also want to address
>> this head-on, not by removing a tangentially related trigger.
>
> VM_NOHUGEPAGE also smells like the wrong thing. This is a file limitation.
>
> !thp_vma_allowable_order() must take care of that somehow down in
> __thp_vma_allowable_orders(), by checking the file).
>
> Likely the file_thp_enabled() check is the culprit with
> CONFIG_READ_ONLY_THP_FOR_FS?
>
> Maybe we need a flag to say "even not CONFIG_READ_ONLY_THP_FOR_FS".
>
> I wonder how we handle that for secretmem. Too late for me, going to bed :)
>

Let me look deeper into this. Thanks!

> --
> Cheers,
>
> David

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[Ackerley Tng]

Ackerley Tng <ackerleytng@google.com> writes:

>
> [...snip...]
>
>> !thp_vma_allowable_order() must take care of that somehow down in
>> __thp_vma_allowable_orders(), by checking the file).
>>
>> Likely the file_thp_enabled() check is the culprit with
>> CONFIG_READ_ONLY_THP_FOR_FS?
>>
>> Maybe we need a flag to say "even not CONFIG_READ_ONLY_THP_FOR_FS".
>>
>> I wonder how we handle that for secretmem. Too late for me, going to bed :)
>>
>
> Let me look deeper into this. Thanks!
>

I trimmed the repro to this:

static void test_guest_memfd_repro(void)
{
	struct kvm_vcpu *vcpu;
	uint8_t *unaligned_mem;
	struct kvm_vm *vm;
	uint8_t *mem;
	int fd;

	vm = __vm_create_shape_with_one_vcpu(VM_SHAPE_DEFAULT, &vcpu, 1, guest_code);

	fd = vm_create_guest_memfd(vm, SZ_2M * 2, GUEST_MEMFD_FLAG_MMAP |
GUEST_MEMFD_FLAG_INIT_SHARED);

	unaligned_mem = mmap(NULL, SZ_2M + SZ_2M, PROT_READ | PROT_WRITE,
MAP_FIXED | MAP_SHARED, fd, 0);
	mem = align_ptr_up(unaligned_mem, SZ_2M);
	TEST_ASSERT(((unsigned long)mem & (SZ_2M - 1)) == 0, "returned
address must be aligned to SZ_2M");

	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_HUGEPAGE), 0);

	for (int i = 0; i < SZ_2M; i += SZ_4K)
		READ_ONCE(mem[i]);

	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_COLLAPSE), 0);

	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_DONTNEED), 0);

	/* This triggers the WARNing. */
	READ_ONCE(mem[0]);

	munmap(unaligned_mem, SZ_2M * 2);

	close(fd);
	kvm_vm_free(vm);
}

And tried to replace the fd creation the secretmem equivalent

	fd = syscall(__NR_memfd_secret, 0);
	TEST_ASSERT(fd >= 0, "Couldn't create secretmem fd.");
	TEST_ASSERT_EQ(ftruncate(fd, SZ_2M * 2), 0);

Should a guest_memfd selftest be added to cover this?

MADV_COLLAPSE fails with EINVAL, but it does go through to
hpage_collapse_scan_file() -> collapse_file(), before failing because
when collapsing the page, copy_mc_highpage() returns > 0.

Not super familiar with copy_mc_highpage() - I haven't looked into why
copy_mc_highpage() failed, but looks like it would have caused
memory_failure_queue() which would be inappropriate.

Since this also affects secretmem, I think thp_vma_allowable_order() is
the best place to intercept the collapsing flow for both secretmem and
guest_memfd.

Let me know if you have any ideas!

>> --
>> Cheers,
>>
>> David

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[Deepanshu Kartikey]

On Sun, Feb 8, 2026 at 11:04 PM Ackerley Tng <ackerleytng@google.com> wrote:
>

> Since this also affects secretmem, I think thp_vma_allowable_order() is
> the best place to intercept the collapsing flow for both secretmem and
> guest_memfd.
>
> Let me know if you have any ideas!
>

Hi David, Ackerley,

I have been looking into this bug and I think the root cause is in
file_thp_enabled(). When CONFIG_READ_ONLY_THP_FOR_FS is enabled,
guest_memfd and secretmem inodes pass the S_ISREG() and
!inode_is_open_for_write() checks, so file_thp_enabled() incorrectly
returns true. This allows khugepaged and MADV_COLLAPSE to create large
folios in the page cache.

I sent a patch that fixes this at the source by explicitly rejecting
GUEST_MEMFD_MAGIC and SECRETMEM_MAGIC in file_thp_enabled():

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 40cf59301c21..4f57c78b57dd 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -93,6 +93,9 @@ static inline bool file_thp_enabled(struct
vm_area_struct *vma)
  return false;

  inode = file_inode(vma->vm_file);
+ if (inode->i_sb->s_magic == GUEST_MEMFD_MAGIC ||
+     inode->i_sb->s_magic == SECRETMEM_MAGIC)
+ return false;

  return !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
 }

I have tested this and confirmed the warning no longer triggers. This
approach covers both guest_memfd and secretmem in one place without
needing separate VMA flag changes in each subsystem. I have sent the
patch.

Please have a look and let me know your thoughts.

Thanks,
Deepanshu

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[David Hildenbrand (Arm)]

On 2/8/26 18:34, Ackerley Tng wrote:
> Ackerley Tng <ackerleytng@google.com> writes:
> 
>>
>> [...snip...]
>>
>>> !thp_vma_allowable_order() must take care of that somehow down in
>>> __thp_vma_allowable_orders(), by checking the file).
>>>
>>> Likely the file_thp_enabled() check is the culprit with
>>> CONFIG_READ_ONLY_THP_FOR_FS?
>>>
>>> Maybe we need a flag to say "even not CONFIG_READ_ONLY_THP_FOR_FS".
>>>
>>> I wonder how we handle that for secretmem. Too late for me, going to bed :)
>>>
>>
>> Let me look deeper into this. Thanks!
>>
> 
> I trimmed the repro to this:
> 
> static void test_guest_memfd_repro(void)
> {
> 	struct kvm_vcpu *vcpu;
> 	uint8_t *unaligned_mem;
> 	struct kvm_vm *vm;
> 	uint8_t *mem;
> 	int fd;
> 
> 	vm = __vm_create_shape_with_one_vcpu(VM_SHAPE_DEFAULT, &vcpu, 1, guest_code);
> 
> 	fd = vm_create_guest_memfd(vm, SZ_2M * 2, GUEST_MEMFD_FLAG_MMAP |
> GUEST_MEMFD_FLAG_INIT_SHARED);
> 
> 	unaligned_mem = mmap(NULL, SZ_2M + SZ_2M, PROT_READ | PROT_WRITE,
> MAP_FIXED | MAP_SHARED, fd, 0);
> 	mem = align_ptr_up(unaligned_mem, SZ_2M);
> 	TEST_ASSERT(((unsigned long)mem & (SZ_2M - 1)) == 0, "returned
> address must be aligned to SZ_2M");
> 
> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_HUGEPAGE), 0);
> 
> 	for (int i = 0; i < SZ_2M; i += SZ_4K)
> 		READ_ONCE(mem[i]);
> 
> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_COLLAPSE), 0);
> 
> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_DONTNEED), 0);
> 
> 	/* This triggers the WARNing. */
> 	READ_ONCE(mem[0]);
> 
> 	munmap(unaligned_mem, SZ_2M * 2);
> 
> 	close(fd);
> 	kvm_vm_free(vm);
> }
> 
> And tried to replace the fd creation the secretmem equivalent
> 
> 	fd = syscall(__NR_memfd_secret, 0);
> 	TEST_ASSERT(fd >= 0, "Couldn't create secretmem fd.");
> 	TEST_ASSERT_EQ(ftruncate(fd, SZ_2M * 2), 0);
> 
> Should a guest_memfd selftest be added to cover this?
> 
> MADV_COLLAPSE fails with EINVAL, but it does go through to
> hpage_collapse_scan_file() -> collapse_file(), before failing because
> when collapsing the page, copy_mc_highpage() returns > 0.

Just what I suspected. :)

Thanks for digging into the details!

-- 
Cheers,

David

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[Ackerley Tng]

"David Hildenbrand (Arm)" <david@kernel.org> writes:

> On 2/8/26 18:34, Ackerley Tng wrote:
>> Ackerley Tng <ackerleytng@google.com> writes:
>>
>>>
>>> [...snip...]
>>>
>>>> !thp_vma_allowable_order() must take care of that somehow down in
>>>> __thp_vma_allowable_orders(), by checking the file).
>>>>
>>>> Likely the file_thp_enabled() check is the culprit with
>>>> CONFIG_READ_ONLY_THP_FOR_FS?
>>>>
>>>> Maybe we need a flag to say "even not CONFIG_READ_ONLY_THP_FOR_FS".
>>>>
>>>> I wonder how we handle that for secretmem. Too late for me, going to bed :)
>>>>
>>>
>>> Let me look deeper into this. Thanks!
>>>
>>
>> I trimmed the repro to this:
>>
>> static void test_guest_memfd_repro(void)
>> {
>> 	struct kvm_vcpu *vcpu;
>> 	uint8_t *unaligned_mem;
>> 	struct kvm_vm *vm;
>> 	uint8_t *mem;
>> 	int fd;
>>
>> 	vm = __vm_create_shape_with_one_vcpu(VM_SHAPE_DEFAULT, &vcpu, 1, guest_code);
>>
>> 	fd = vm_create_guest_memfd(vm, SZ_2M * 2, GUEST_MEMFD_FLAG_MMAP |
>> GUEST_MEMFD_FLAG_INIT_SHARED);
>>
>> 	unaligned_mem = mmap(NULL, SZ_2M + SZ_2M, PROT_READ | PROT_WRITE,
>> MAP_FIXED | MAP_SHARED, fd, 0);
>> 	mem = align_ptr_up(unaligned_mem, SZ_2M);
>> 	TEST_ASSERT(((unsigned long)mem & (SZ_2M - 1)) == 0, "returned
>> address must be aligned to SZ_2M");
>>
>> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_HUGEPAGE), 0);
>>
>> 	for (int i = 0; i < SZ_2M; i += SZ_4K)
>> 		READ_ONCE(mem[i]);
>>
>> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_COLLAPSE), 0);
>>
>> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_DONTNEED), 0);
>>
>> 	/* This triggers the WARNing. */
>> 	READ_ONCE(mem[0]);
>>
>> 	munmap(unaligned_mem, SZ_2M * 2);
>>
>> 	close(fd);
>> 	kvm_vm_free(vm);
>> }
>>
>> And tried to replace the fd creation the secretmem equivalent
>>
>> 	fd = syscall(__NR_memfd_secret, 0);
>> 	TEST_ASSERT(fd >= 0, "Couldn't create secretmem fd.");
>> 	TEST_ASSERT_EQ(ftruncate(fd, SZ_2M * 2), 0);
>>
>> Should a guest_memfd selftest be added to cover this?
>>
>> MADV_COLLAPSE fails with EINVAL, but it does go through to
>> hpage_collapse_scan_file() -> collapse_file(), before failing because
>> when collapsing the page, copy_mc_highpage() returns > 0.
>
> Just what I suspected. :)
>
> Thanks for digging into the details!
>

Happy to help :)

In general, do we want the reproducers added as selftests? Should this
be added as part of tools/testing/selftests/kvm/guest_memfd_test.c or a
separate file?

> --
> Cheers,
>
> David

Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND

[David Hildenbrand (Arm)]

On 2/9/26 19:24, Ackerley Tng wrote:
> "David Hildenbrand (Arm)" <david@kernel.org> writes:
> 
>> On 2/8/26 18:34, Ackerley Tng wrote:
>>> Ackerley Tng <ackerleytng@google.com> writes:
>>>
>>>
>>> I trimmed the repro to this:
>>>
>>> static void test_guest_memfd_repro(void)
>>> {
>>> 	struct kvm_vcpu *vcpu;
>>> 	uint8_t *unaligned_mem;
>>> 	struct kvm_vm *vm;
>>> 	uint8_t *mem;
>>> 	int fd;
>>>
>>> 	vm = __vm_create_shape_with_one_vcpu(VM_SHAPE_DEFAULT, &vcpu, 1, guest_code);
>>>
>>> 	fd = vm_create_guest_memfd(vm, SZ_2M * 2, GUEST_MEMFD_FLAG_MMAP |
>>> GUEST_MEMFD_FLAG_INIT_SHARED);
>>>
>>> 	unaligned_mem = mmap(NULL, SZ_2M + SZ_2M, PROT_READ | PROT_WRITE,
>>> MAP_FIXED | MAP_SHARED, fd, 0);
>>> 	mem = align_ptr_up(unaligned_mem, SZ_2M);
>>> 	TEST_ASSERT(((unsigned long)mem & (SZ_2M - 1)) == 0, "returned
>>> address must be aligned to SZ_2M");
>>>
>>> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_HUGEPAGE), 0);
>>>
>>> 	for (int i = 0; i < SZ_2M; i += SZ_4K)
>>> 		READ_ONCE(mem[i]);
>>>
>>> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_COLLAPSE), 0);
>>>
>>> 	TEST_ASSERT_EQ(madvise(mem, SZ_2M, MADV_DONTNEED), 0);
>>>
>>> 	/* This triggers the WARNing. */
>>> 	READ_ONCE(mem[0]);
>>>
>>> 	munmap(unaligned_mem, SZ_2M * 2);
>>>
>>> 	close(fd);
>>> 	kvm_vm_free(vm);
>>> }
>>>
>>> And tried to replace the fd creation the secretmem equivalent
>>>
>>> 	fd = syscall(__NR_memfd_secret, 0);
>>> 	TEST_ASSERT(fd >= 0, "Couldn't create secretmem fd.");
>>> 	TEST_ASSERT_EQ(ftruncate(fd, SZ_2M * 2), 0);
>>>
>>> Should a guest_memfd selftest be added to cover this?
>>>
>>> MADV_COLLAPSE fails with EINVAL, but it does go through to
>>> hpage_collapse_scan_file() -> collapse_file(), before failing because
>>> when collapsing the page, copy_mc_highpage() returns > 0.
>>
>> Just what I suspected. :)
>>
>> Thanks for digging into the details!
>>
> 
> Happy to help :)
> 
> In general, do we want the reproducers added as selftests? Should this
> be added as part of tools/testing/selftests/kvm/guest_memfd_test.c

I guess adding it to guest_memfd_test.c and asserting that MADV_COLLAPSE 
fails as expected could be a reasonable test case. It's not a lot of 
code and easy to verify.

-- 
Cheers,

David

Forwarded: [PATCH] KVM: guest_memfd: Prevent THP collapse of guest_memfd pages

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] KVM: guest_memfd: Prevent THP collapse of guest_memfd pages
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

guest_memfd fault handler kvm_gmem_fault_user_mapping() does not support
large folios and warns via WARN_ON_ONCE(folio_test_large(folio)).

When a guest_memfd mapping has VM_HUGEPAGE set via madvise(MADV_HUGEPAGE),
khugepaged or MADV_COLLAPSE can collapse small pages into a large folio
in the page cache. This happens because file_thp_enabled() incorrectly
returns true for guest_memfd inodes when CONFIG_READ_ONLY_THP_FOR_FS is
enabled. A subsequent page fault finds the large folio and triggers the
warning.

Fix this by setting VM_NO_KHUGEPAGED on the VMA in kvm_gmem_mmap().
This causes __thp_vma_allowable_orders() to reject THP early for both
MADV_COLLAPSE and khugepaged. The page fault path is unaffected since
guest_memfd does not define a huge_fault handler.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 virt/kvm/guest_memfd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..94ac360afe79 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -474,12 +474,13 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma)
 {
 	if (!kvm_gmem_supports_mmap(file_inode(file)))
 		return -ENODEV;
-
+	
 	if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) !=
 	    (VM_SHARED | VM_MAYSHARE)) {
 		return -EINVAL;
 	}
 
+	vm_flags_set(vma, VM_NO_KHUGEPAGED);
 	vma->vm_ops = &kvm_gmem_vm_ops;
 
 	return 0;
-- 
2.43.0

Forwarded: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in file_thp_enabled()

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in file_thp_enabled()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

file_thp_enabled() incorrectly returns true for guest_memfd and secretmem
inodes because they appear as regular read-only files when
CONFIG_READ_ONLY_THP_FOR_FS is enabled. This allows khugepaged and
MADV_COLLAPSE to create large folios in the page cache, but their fault
handlers do not support large folios.

Add explicit checks for GUEST_MEMFD_MAGIC and SECRETMEM_MAGIC to reject
these filesystems early in file_thp_enabled().

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 mm/huge_memory.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 40cf59301c21..4f57c78b57dd 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -93,6 +93,9 @@ static inline bool file_thp_enabled(struct vm_area_struct *vma)
 		return false;
 
 	inode = file_inode(vma->vm_file);
+	if (inode->i_sb->s_magic == GUEST_MEMFD_MAGIC ||
+	    inode->i_sb->s_magic == SECRETMEM_MAGIC)
+		return false;
 
 	return !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
 }
-- 
2.43.0

Forwarded: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in file_thp_enabled()

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in file_thp_enabled()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


file_thp_enabled() incorrectly returns true for guest_memfd and secretmem
inodes because they use alloc_file_pseudo() which does not call
get_write_access(), leaving i_writecount at 0. Combined with S_ISREG being
true, these pseudo-filesystem inodes appear as read-only regular files when
CONFIG_READ_ONLY_THP_FOR_FS is enabled.

This allows khugepaged and MADV_COLLAPSE to create large folios in the
page cache via the TVA_COLLAPSE path, but their fault handlers do not
support large folios. For guest_memfd this triggers
WARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().

Introduce AS_NO_READ_ONLY_THP_FOR_FS address_space flag to allow
filesystems to opt out of CONFIG_READ_ONLY_THP_FOR_FS. Set this flag
in both guest_memfd and secretmem inode setup. This flag can be easily
removed along with CONFIG_READ_ONLY_THP_FOR_FS when it goes away.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
 include/linux/pagemap.h | 1 +
 mm/huge_memory.c        | 3 +++
 mm/secretmem.c          | 3 ++-
 virt/kvm/guest_memfd.c  | 1 +
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index ec442af3f886..23f559fc1a4c 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -211,6 +211,7 @@ enum mapping_flags {
 	AS_KERNEL_FILE = 10,	/* mapping for a fake kernel file that shouldn't
 				   account usage to user cgroups */
 	AS_NO_DATA_INTEGRITY = 11, /* no data integrity guarantees */
+	AS_NO_READ_ONLY_THP_FOR_FS = 12,
 	/* Bits 16-25 are used for FOLIO_ORDER */
 	AS_FOLIO_ORDER_BITS = 5,
 	AS_FOLIO_ORDER_MIN = 16,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 40cf59301c21..4bdda92ce01e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -94,6 +94,9 @@ static inline bool file_thp_enabled(struct vm_area_struct *vma)
 
 	inode = file_inode(vma->vm_file);
 
+	if (test_bit(AS_NO_READ_ONLY_THP_FOR_FS, &inode->i_mapping->flags))
+		return false;
+
 	return !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
 }
 
diff --git a/mm/secretmem.c b/mm/secretmem.c
index edf111e0a1bb..56d93a74f5fc 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -205,7 +205,8 @@ static struct file *secretmem_file_create(unsigned long flags)
 
 	mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
 	mapping_set_unevictable(inode->i_mapping);
-
+	set_bit(AS_NO_READ_ONLY_THP_FOR_FS, &inode->i_mapping->flags);
+	
 	inode->i_op = &secretmem_iops;
 	inode->i_mapping->a_ops = &secretmem_aops;
 
diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..b93a324c81bd 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -597,6 +597,7 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	inode->i_size = size;
 	mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
 	mapping_set_inaccessible(inode->i_mapping);
+	set_bit(AS_NO_READ_ONLY_THP_FOR_FS, &inode->i_mapping->flags);
 	/* Unmovable mappings are supposed to be marked unevictable as well. */
 	WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping));
 
-- 
2.43.0

Forwarded: [PATCH] mm: thp: deny THP for files on anonymous inodes

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm: thp: deny THP for files on anonymous inodes
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

file_thp_enabled() incorrectly allows THP for files on anonymous inodes
(e.g. guest_memfd and secretmem). These files are created via
alloc_file_pseudo(), which does not call get_write_access() and leaves
inode->i_writecount at 0. Combined with S_ISREG(inode->i_mode) being
true, they appear as read-only regular files when
CONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP
collapse.

Anonymous inodes can never pass the inode_is_open_for_write() check
since their i_writecount is never incremented through the normal VFS
open path. The right thing to do is to exclude them from THP eligibility
altogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real
filesystem files (e.g. shared libraries), not for pseudo-filesystem
inodes.

For guest_memfd, this allows khugepaged and MADV_COLLAPSE to create
large folios in the page cache via the collapse path, but the
guest_memfd fault handler does not support large folios. This triggers
WARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().

For secretmem, collapse_file() tries to copy page contents through the
direct map, but secretmem pages are removed from the direct map. This
can result in a kernel crash:

    BUG: unable to handle page fault for address: ffff88810284d000
    RIP: 0010:memcpy_orig+0x16/0x130
    Call Trace:
     collapse_file
     hpage_collapse_scan_file
     madvise_collapse

Secretmem is not affected by the crash on upstream as the memory failure
recovery handles the failed copy gracefully, but it still triggers
confusing false memory failure reports:

    Memory failure: 0x106d96f: recovery action for clean unevictable
    LRU page: Recovered

Check IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all
anonymous inode files.

Link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Link: https://lore.kernel.org/linux-mm/CAEvNRgHegcz3ro35ixkDw39ES8=U6rs6S7iP0gkR9enr7HoGtA@mail.gmail.com
Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Fixes: 7fbb5e188248 ("mm: remove VM_EXEC requirement for THP eligibility")
Cc: stable@vger.kernel.org
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
v2:
  - Use IS_ANON_FILE(inode) to deny THP for all anonymous inode files
    instead of checking for specific subsystems (David Hildenbrand)
  - Updated Fixes tag to 7fbb5e188248 which removed the VM_EXEC
    requirement that accidentally protected secretmem
  - Expanded commit message with implications for both guest_memfd
    and secretmem
---
 mm/huge_memory.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 40cf59301c21..d3beddd8cc30 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -94,6 +94,9 @@ static inline bool file_thp_enabled(struct vm_area_struct *vma)
 
 	inode = file_inode(vma->vm_file);
 
+	if (IS_ANON_FILE(inode))
+		return false;
+
 	return !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
 }
 
-- 
2.43.0

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in kvm_gmem_fault_user_mapping

------------[ cut here ]------------
folio_test_large(folio)
WARNING: arch/x86/kvm/../../../virt/kvm/guest_memfd.c:416 at kvm_gmem_fault_user_mapping+0x4b5/0x6e0 virt/kvm/guest_memfd.c:416, CPU#1: syz.3.91/7037
Modules linked in:
CPU: 1 UID: 0 PID: 7037 Comm: syz.3.91 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:kvm_gmem_fault_user_mapping+0x4b5/0x6e0 virt/kvm/guest_memfd.c:416
Code: 00 e9 a1 fe ff ff bd 00 04 00 00 eb d9 e8 43 b8 83 00 48 c7 c6 e0 9f 82 8b 48 89 df e8 54 fb ce 00 90 0f 0b e8 2c b8 83 00 90 <0f> 0b 90 48 8d 6b 34 48 89 df e8 ec f6 bb 00 be 04 00 00 00 48 89
RSP: 0018:ffffc90004477848 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffea0001c10000 RCX: ffffffff81834070
RDX: ffff88802e784980 RSI: ffffffff81834334 RDI: ffff88802e784980
RBP: ffffc900044779f8 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000040 R11: 0000000000000000 R12: ffffea0001c10000
R13: ffffc90004477a08 R14: 0000000000000040 R15: ffffea0001c10008
FS:  00007f25057f76c0(0000) GS:ffff8881246d9000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6a111b7d58 CR3: 00000000310af000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 __do_fault+0x10d/0x550 mm/memory.c:5323
 do_read_fault mm/memory.c:5758 [inline]
 do_fault+0xaf9/0x1990 mm/memory.c:5892
 do_pte_missing mm/memory.c:4404 [inline]
 handle_pte_fault mm/memory.c:6276 [inline]
 __handle_mm_fault+0x1807/0x2b50 mm/memory.c:6414
 handle_mm_fault+0x36d/0xa20 mm/memory.c:6583
 faultin_page mm/gup.c:1126 [inline]
 __get_user_pages+0xf9c/0x34d0 mm/gup.c:1428
 populate_vma_page_range+0x267/0x3f0 mm/gup.c:1860
 __mm_populate+0x107/0x3a0 mm/gup.c:1963
 do_mlock+0x3f0/0x7f0 mm/mlock.c:653
 __do_sys_mlock mm/mlock.c:661 [inline]
 __se_sys_mlock mm/mlock.c:659 [inline]
 __x64_sys_mlock+0x59/0x80 mm/mlock.c:659
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f250499aeb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f25057f7028 EFLAGS: 00000246 ORIG_RAX: 0000000000000095
RAX: ffffffffffffffda RBX: 00007f2504c15fa0 RCX: 00007f250499aeb9
RDX: 0000000000000000 RSI: 0000000000800000 RDI: 0000200000000000
RBP: 00007f2504a08c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f2504c16038 R14: 00007f2504c15fa0 R15: 00007ffc912316c8
 </TASK>


Tested on:

commit:         162b4244 Merge tag 'iommu-fixes-v6.19-rc7' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14d7053a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1048d322580000

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com

Tested on:

commit:         162b4244 Merge tag 'iommu-fixes-v6.19-rc7' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14a0445a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=167abbfa580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in kvm_gmem_create

------------[ cut here ]------------
!mapping_unevictable(inode->i_mapping)
WARNING: arch/x86/kvm/../../../virt/kvm/guest_memfd.c:601 at __kvm_gmem_create virt/kvm/guest_memfd.c:601 [inline], CPU#0: syz.0.17/6689
WARNING: arch/x86/kvm/../../../virt/kvm/guest_memfd.c:601 at kvm_gmem_create+0x389/0x780 virt/kvm/guest_memfd.c:644, CPU#0: syz.0.17/6689
Modules linked in:
CPU: 0 UID: 0 PID: 6689 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:__kvm_gmem_create virt/kvm/guest_memfd.c:601 [inline]
RIP: 0010:kvm_gmem_create+0x389/0x780 virt/kvm/guest_memfd.c:644
Code: 0f 85 88 03 00 00 4d 8b ad 28 01 00 00 31 ff 49 c1 ed 03 41 83 e5 01 44 89 ee e8 c2 ac 83 00 45 84 ed 75 09 e8 68 b2 83 00 90 <0f> 0b 90 e8 5f b2 83 00 49 8d bf 78 04 00 00 48 b8 00 00 00 00 00
RSP: 0018:ffffc90003f97990 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff818348ee
RDX: ffff88801ebb24c0 RSI: ffffffff818348f8 RDI: ffff88801ebb24c0
RBP: ffff88805dae0000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: ffffffff82711c34 R12: ffff88801ffd5d00
R13: 0000000000000000 R14: 0000000000000003 R15: ffff88806b738048
FS:  00007f124fe386c0(0000) GS:ffff8881245d9000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b34963fff CR3: 000000002a3f2000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 kvm_vm_ioctl+0x1109/0x4020 virt/kvm/kvm_main.c:5397
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:597 [inline]
 __se_sys_ioctl fs/ioctl.c:583 [inline]
 __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f124ef9aeb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f124fe38028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f124f215fa0 RCX: 00007f124ef9aeb9
RDX: 00002000000001c0 RSI: 00000000c040aed4 RDI: 0000000000000004
RBP: 00007f124f008c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f124f216038 R14: 00007f124f215fa0 R15: 00007ffc8cc39a38
 </TASK>


Tested on:

commit:         162b4244 Merge tag 'iommu-fixes-v6.19-rc7' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1039bbfa580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=161ebbfa580000

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in kvm_gmem_fault_user_mapping

------------[ cut here ]------------
folio_test_large(folio)
WARNING: arch/x86/kvm/../../../virt/kvm/guest_memfd.c:416 at kvm_gmem_fault_user_mapping+0x4b5/0x6e0 virt/kvm/guest_memfd.c:416, CPU#0: syz.1.84/6725
Modules linked in:
CPU: 0 UID: 0 PID: 6725 Comm: syz.1.84 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:kvm_gmem_fault_user_mapping+0x4b5/0x6e0 virt/kvm/guest_memfd.c:416
Code: 00 e9 a1 fe ff ff bd 00 04 00 00 eb d9 e8 43 b8 83 00 48 c7 c6 e0 9f 82 8b 48 89 df e8 54 fb ce 00 90 0f 0b e8 2c b8 83 00 90 <0f> 0b 90 48 8d 6b 34 48 89 df e8 ec f6 bb 00 be 04 00 00 00 48 89
RSP: 0018:ffffc90004d4f848 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffea0001380000 RCX: ffffffff81834070
RDX: ffff88802f604980 RSI: ffffffff81834334 RDI: ffff88802f604980
RBP: ffffc90004d4f9f8 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000040 R11: 0000000000000000 R12: ffffea0001380000
R13: ffffc90004d4fa08 R14: 0000000000000040 R15: ffffea0001380008
FS:  00007efea6edc6c0(0000) GS:ffff8881245d9000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0db714da08 CR3: 000000005a1f9000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 __do_fault+0x10d/0x550 mm/memory.c:5323
 do_read_fault mm/memory.c:5758 [inline]
 do_fault+0xaf9/0x1990 mm/memory.c:5892
 do_pte_missing mm/memory.c:4404 [inline]
 handle_pte_fault mm/memory.c:6276 [inline]
 __handle_mm_fault+0x1807/0x2b50 mm/memory.c:6414
 handle_mm_fault+0x36d/0xa20 mm/memory.c:6583
 faultin_page mm/gup.c:1126 [inline]
 __get_user_pages+0xf9c/0x34d0 mm/gup.c:1428
 populate_vma_page_range+0x267/0x3f0 mm/gup.c:1860
 __mm_populate+0x107/0x3a0 mm/gup.c:1963
 do_mlock+0x3f0/0x7f0 mm/mlock.c:653
 __do_sys_mlock mm/mlock.c:661 [inline]
 __se_sys_mlock mm/mlock.c:659 [inline]
 __x64_sys_mlock+0x59/0x80 mm/mlock.c:659
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7efea5f9aeb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007efea6edc028 EFLAGS: 00000246 ORIG_RAX: 0000000000000095
RAX: ffffffffffffffda RBX: 00007efea6215fa0 RCX: 00007efea5f9aeb9
RDX: 0000000000000000 RSI: 0000000000800000 RDI: 0000200000000000
RBP: 00007efea6008c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007efea6216038 R14: 00007efea6215fa0 R15: 00007ffd595ac0c8
 </TASK>


Tested on:

commit:         162b4244 Merge tag 'iommu-fixes-v6.19-rc7' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10fde45a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=116de45a580000

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
kernel BUG in filemap_remove_folio

------------[ cut here ]------------
kernel BUG at mm/filemap.c:254!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 1 UID: 0 PID: 7475 Comm: syz.2.329 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:filemap_remove_folio+0x20f/0x270 mm/filemap.c:254
Code: fc 00 10 00 00 0f 86 5f ff ff ff eb 9e e8 b9 e5 c6 ff 48 c7 c6 20 0d 9d 8b 48 89 df e8 6a 2a 12 00 90 0f 0b e8 a2 e5 c6 ff 90 <0f> 0b e8 9a 38 31 00 e9 39 fe ff ff e8 90 38 31 00 e9 0c fe ff ff
RSP: 0018:ffffc9000caaf7f0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffea0001400000 RCX: ffffffff8240149d
RDX: ffff88802bcaa4c0 RSI: ffffffff824015fe RDI: ffff88802bcaa4c0
RBP: ffff88806b3047b0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88806b3045c0 R14: 0000000000000000 R15: 1000200001ee0000
FS:  00007fa5c3e506c0(0000) GS:ffff8881246d9000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000572cf000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 kvm_gmem_get_folio+0x118/0x320 virt/kvm/guest_memfd.c:166
 kvm_gmem_fault_user_mapping+0x151/0x6e0 virt/kvm/guest_memfd.c:425
 __do_fault+0x10d/0x550 mm/memory.c:5323
 do_read_fault mm/memory.c:5758 [inline]
 do_fault+0xaf9/0x1990 mm/memory.c:5892
 do_pte_missing mm/memory.c:4404 [inline]
 handle_pte_fault mm/memory.c:6276 [inline]
 __handle_mm_fault+0x1807/0x2b50 mm/memory.c:6414
 handle_mm_fault+0x36d/0xa20 mm/memory.c:6583
 faultin_page mm/gup.c:1126 [inline]
 __get_user_pages+0xf9c/0x34d0 mm/gup.c:1428
 populate_vma_page_range+0x267/0x3f0 mm/gup.c:1860
 __mm_populate+0x107/0x3a0 mm/gup.c:1963
 do_mlock+0x3f0/0x7f0 mm/mlock.c:653
 __do_sys_mlock mm/mlock.c:661 [inline]
 __se_sys_mlock mm/mlock.c:659 [inline]
 __x64_sys_mlock+0x59/0x80 mm/mlock.c:659
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa5c2f9aeb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fa5c3e50028 EFLAGS: 00000246 ORIG_RAX: 0000000000000095
RAX: ffffffffffffffda RBX: 00007fa5c3215fa0 RCX: 00007fa5c2f9aeb9
RDX: 0000000000000000 RSI: 0000000000800000 RDI: 0000200000000000
RBP: 00007fa5c3008c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fa5c3216038 R14: 00007fa5c3215fa0 R15: 00007fff2603f848
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:filemap_remove_folio+0x20f/0x270 mm/filemap.c:254
Code: fc 00 10 00 00 0f 86 5f ff ff ff eb 9e e8 b9 e5 c6 ff 48 c7 c6 20 0d 9d 8b 48 89 df e8 6a 2a 12 00 90 0f 0b e8 a2 e5 c6 ff 90 <0f> 0b e8 9a 38 31 00 e9 39 fe ff ff e8 90 38 31 00 e9 0c fe ff ff
RSP: 0018:ffffc9000caaf7f0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffea0001400000 RCX: ffffffff8240149d
RDX: ffff88802bcaa4c0 RSI: ffffffff824015fe RDI: ffff88802bcaa4c0
RBP: ffff88806b3047b0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88806b3045c0 R14: 0000000000000000 R15: 1000200001ee0000
FS:  00007fa5c3e506c0(0000) GS:ffff8881245d9000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000572cf000 CR4: 00000000003526f0


Tested on:

commit:         18f7fcd5 Linux 6.19-rc8
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14e73322580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=17ca453a580000

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com

Tested on:

commit:         18f7fcd5 Linux 6.19-rc8
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14ced644580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10b5c45a580000

Note: testing is done by a robot and is best-effort only.

[PATCH 1/2] KVM: guest_memfd: Always use order 0 when allocating for guest_memfd

[Ackerley Tng]

#syz test: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next

filemap_{grab,get}_folio() and related functions, used since the early
stages of guest_memfd have determined the order of the folio to be
allocated by looking up mapping_min_folio_order(mapping). As identified by
syzbot, MADV_HUGEPAGE can be used to set the result of
mapping_min_folio_order() to a value greater than 0, leading to the
allocation of a huge page and subsequent WARNing.

Refactor the allocation code of guest_memfd to directly use
filemap_add_folio(), specifying an order of 0.

This refactoring replaces the original functionality where FGP_LOCK and
FGP_CREAT are requested. Opportunistically drop functionality provided by
FGP_ACCESSED. guest_memfd folios don't care about accessed flags because
guest_memfd memory is unevictable and there is no storage to write back to.

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
 virt/kvm/guest_memfd.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index fdaea3422c30..0c58f6aa5609 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -135,23 +135,35 @@ static struct folio *kvm_gmem_get_folio(struct inode *inode, pgoff_t index)
 	/* TODO: Support huge pages. */
 	struct mempolicy *policy;
 	struct folio *folio;
+	gfp_t gfp;
+	int ret;

 	/*
 	 * Fast-path: See if folio is already present in mapping to avoid
 	 * policy_lookup.
 	 */
+repeat:
 	folio = __filemap_get_folio(inode->i_mapping, index,
 				    FGP_LOCK | FGP_ACCESSED, 0);
 	if (!IS_ERR(folio))
 		return folio;

+	gfp = mapping_gfp_mask(inode->i_mapping);
+
 	policy = mpol_shared_policy_lookup(&GMEM_I(inode)->policy, index);
-	folio = __filemap_get_folio_mpol(inode->i_mapping, index,
-					 FGP_LOCK | FGP_ACCESSED | FGP_CREAT,
-					 mapping_gfp_mask(inode->i_mapping), policy);
+	folio = filemap_alloc_folio(gfp, 0, policy);
 	mpol_cond_put(policy);
+	if (!folio)
+		return ERR_PTR(-ENOMEM);

-	return folio;
+	ret = filemap_add_folio(inode->i_mapping, folio, index, gfp);
+	if (ret)
+		folio_put(folio);
+
+	if (ret == -EEXIST)
+		goto repeat;
+
+	return ret ? ERR_PTR(ret) : folio;
 }

 static enum kvm_gfn_range_filter kvm_gmem_get_invalidate_filter(struct inode *inode)
--
2.53.0.rc2.204.g2597b5adb4-goog

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

[ T5892] bridge0: port 1(bridge_slave_0) entered disabled state
[   81.250782][ T5892] bridge_slave_0: entered allmulticast mode
[   81.258962][ T5892] bridge_slave_0: entered promiscuous mode
[   81.278262][ T5892] bridge0: port 2(bridge_slave_1) entered blocking state
[   81.285839][ T5892] bridge0: port 2(bridge_slave_1) entered disabled state
[   81.293092][ T5892] bridge_slave_1: entered allmulticast mode
[   81.300579][ T5892] bridge_slave_1: entered promiscuous mode
[   81.323935][ T5892] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
[   81.334917][ T5892] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
[   81.359447][ T5892] team0: Port device team_slave_0 added
[   81.367513][ T5892] team0: Port device team_slave_1 added
[   81.408524][ T5892] batman_adv: batadv0: Adding interface: batadv_slave_0
[   81.415517][ T5892] batman_adv: batadv0: The MTU of interface batadv_slave_0 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[   81.441455][ T5892] batman_adv: batadv0: Not using interface batadv_slave_0 (retrying later): interface not active
[   81.453632][ T5892] batman_adv: batadv0: Adding interface: batadv_slave_1
[   81.460613][ T5892] batman_adv: batadv0: The MTU of interface batadv_slave_1 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[   81.488313][  T925] cfg80211: failed to load regulatory.db
[   81.495132][ T5892] batman_adv: batadv0: Not using interface batadv_slave_1 (retrying later): interface not active
[   81.579848][ T5892] hsr_slave_0: entered promiscuous mode
[   81.586459][ T5892] hsr_slave_1: entered promiscuous mode
[   81.772551][ T5892] netdevsim netdevsim1 netdevsim0: renamed from eth0
[   81.785274][ T5892] netdevsim netdevsim1 netdevsim1: renamed from eth1
[   81.794987][ T5892] netdevsim netdevsim1 netdevsim2: renamed from eth2
[   81.804459][ T5892] netdevsim netdevsim1 netdevsim3: renamed from eth3
[   81.830752][ T5892] bridge0: port 2(bridge_slave_1) entered blocking state
[   81.837931][ T5892] bridge0: port 2(bridge_slave_1) entered forwarding state
[   81.846102][ T5892] bridge0: port 1(bridge_slave_0) entered blocking state
[   81.853188][ T5892] bridge0: port 1(bridge_slave_0) entered forwarding state
[   81.897540][ T5892] 8021q: adding VLAN 0 to HW filter on device bond0
[   81.910890][ T1309] bridge0: port 1(bridge_slave_0) entered disabled state
[   81.920082][ T1309] bridge0: port 2(bridge_slave_1) entered disabled state
[   81.938230][ T5892] 8021q: adding VLAN 0 to HW filter on device team0
[   81.950068][ T4559] bridge0: port 1(bridge_slave_0) entered blocking state
[   81.957340][ T4559] bridge0: port 1(bridge_slave_0) entered forwarding state
[   81.970244][ T1309] bridge0: port 2(bridge_slave_1) entered blocking state
[   81.977416][ T1309] bridge0: port 2(bridge_slave_1) entered forwarding state
[   82.117812][ T5892] 8021q: adding VLAN 0 to HW filter on device batadv0
[   82.154991][ T5892] veth0_vlan: entered promiscuous mode
[   82.165350][ T5892] veth1_vlan: entered promiscuous mode
[   82.191094][ T5892] veth0_macvtap: entered promiscuous mode
[   82.199927][ T5892] veth1_macvtap: entered promiscuous mode
[   82.216210][ T5892] batman_adv: batadv0: Interface activated: batadv_slave_0
[   82.231786][ T5892] batman_adv: batadv0: Interface activated: batadv_slave_1
[   82.244797][ T1309] netdevsim netdevsim1 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0
[   82.261190][ T1309] netdevsim netdevsim1 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0
[   82.270821][ T1309] netdevsim netdevsim1 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0
[   82.284641][ T1309] netdevsim netdevsim1 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0
2026/02/03 21:59:31 executed programs: 0
[   82.372872][ T5875] Bluetooth: hci0: unexpected cc 0x0c03 length: 249 > 1
[   82.382293][ T5875] Bluetooth: hci0: unexpected cc 0x1003 length: 249 > 9
[   82.390483][ T5875] Bluetooth: hci0: unexpected cc 0x1001 length: 249 > 9
[   82.399377][ T5875] Bluetooth: hci0: unexpected cc 0x0c23 length: 249 > 4
[   82.407179][ T5875] Bluetooth: hci0: unexpected cc 0x0c38 length: 249 > 2
[   82.532003][ T5934] chnl_net:caif_netlink_parms(): no params data found
[   82.594483][ T5934] bridge0: port 1(bridge_slave_0) entered blocking state
[   82.602243][ T5934] bridge0: port 1(bridge_slave_0) entered disabled state
[   82.609657][ T5934] bridge_slave_0: entered allmulticast mode
[   82.616572][ T5934] bridge_slave_0: entered promiscuous mode
[   82.626770][ T5934] bridge0: port 2(bridge_slave_1) entered blocking state
[   82.634336][ T5934] bridge0: port 2(bridge_slave_1) entered disabled state
[   82.641777][ T5934] bridge_slave_1: entered allmulticast mode
[   82.648703][ T5934] bridge_slave_1: entered promiscuous mode
[   82.680172][ T5934] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
[   82.691594][ T5934] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
[   82.716205][ T5934] team0: Port device team_slave_0 added
[   82.723696][ T5934] team0: Port device team_slave_1 added
[   82.743136][ T5934] batman_adv: batadv0: Adding interface: batadv_slave_0
[   82.750263][ T5934] batman_adv: batadv0: The MTU of interface batadv_slave_0 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[   82.777401][ T5934] batman_adv: batadv0: Not using interface batadv_slave_0 (retrying later): interface not active
[   82.789795][ T5934] batman_adv: batadv0: Adding interface: batadv_slave_1
[   82.796831][ T5934] batman_adv: batadv0: The MTU of interface batadv_slave_1 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[   82.822826][ T5934] batman_adv: batadv0: Not using interface batadv_slave_1 (retrying later): interface not active
[   82.861709][ T5934] hsr_slave_0: entered promiscuous mode
[   82.868122][ T5934] hsr_slave_1: entered promiscuous mode
[   82.874061][ T5934] debugfs: 'hsr0' already exists in 'hsr'
[   82.879937][ T5934] Cannot create hsr debugfs directory
[   82.991829][ T5934] netdevsim netdevsim0 netdevsim0: renamed from eth0
[   83.001861][ T5934] netdevsim netdevsim0 netdevsim1: renamed from eth1
[   83.013215][ T5934] netdevsim netdevsim0 netdevsim2: renamed from eth2
[   83.023136][ T5934] netdevsim netdevsim0 netdevsim3: renamed from eth3
[   83.050741][ T5934] bridge0: port 2(bridge_slave_1) entered blocking state
[   83.057927][ T5934] bridge0: port 2(bridge_slave_1) entered forwarding state
[   83.065345][ T5934] bridge0: port 1(bridge_slave_0) entered blocking state
[   83.072413][ T5934] bridge0: port 1(bridge_slave_0) entered forwarding state
[   83.120031][ T5934] 8021q: adding VLAN 0 to HW filter on device bond0
[   83.134601][   T13] bridge0: port 1(bridge_slave_0) entered disabled state
[   83.142944][   T13] bridge0: port 2(bridge_slave_1) entered disabled state
[   83.158979][ T5934] 8021q: adding VLAN 0 to HW filter on device team0
[   83.170550][   T13] bridge0: port 1(bridge_slave_0) entered blocking state
[   83.177700][   T13] bridge0: port 1(bridge_slave_0) entered forwarding state
[   83.190625][   T13] bridge0: port 2(bridge_slave_1) entered blocking state
[   83.197827][   T13] bridge0: port 2(bridge_slave_1) entered forwarding state
[   83.341329][ T5934] 8021q: adding VLAN 0 to HW filter on device batadv0
[   83.378958][ T5934] veth0_vlan: entered promiscuous mode
[   83.389241][ T5934] veth1_vlan: entered promiscuous mode
[   83.415371][ T5934] veth0_macvtap: entered promiscuous mode
[   83.427514][ T5934] veth1_macvtap: entered promiscuous mode
[   83.442500][ T5934] batman_adv: batadv0: Interface activated: batadv_slave_0
[   83.457848][ T5934] batman_adv: batadv0: Interface activated: batadv_slave_1
[   83.470032][   T13] netdevsim netdevsim0 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0
[   83.481273][   T13] netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0
[   83.491068][ T1309] netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0
[   83.503898][ T1309] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0
[   83.557255][   T13] wlan0: Created IBSS using preconfigured BSSID 50:50:50:50:50:50
[   83.570502][   T13] wlan0: Creating new IBSS network, BSSID 50:50:50:50:50:50
[   83.593580][ T4559] wlan1: Created IBSS using preconfigured BSSID 50:50:50:50:50:50
[   83.602431][ T4559] wlan1: Creating new IBSS network, BSSID 50:50:50:50:50:50
[   84.168287][ T4559] netdevsim netdevsim1 netdevsim3 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
[   85.956893][ T4559] netdevsim netdevsim1 netdevsim2 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
[   86.015502][ T4559] netdevsim netdevsim1 netdevsim1 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
[   86.093966][ T4559] netdevsim netdevsim1 netdevsim0 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
[   86.188820][ T4559] bridge_slave_1: left allmulticast mode
[   86.194577][ T4559] bridge_slave_1: left promiscuous mode
[   86.202899][ T4559] bridge0: port 2(bridge_slave_1) entered disabled state
[   86.214213][ T4559] bridge_slave_0: left allmulticast mode
[   86.220656][ T4559] bridge_slave_0: left promiscuous mode
[   86.226590][ T4559] bridge0: port 1(bridge_slave_0) entered disabled state
[   86.433971][ T4559] bond0 (unregistering): (slave bond_slave_0): Releasing backup interface
[   86.445424][ T4559] bond0 (unregistering): (slave bond_slave_1): Releasing backup interface
[   86.454915][ T4559] bond0 (unregistering): Released all slaves
[   86.751537][ T4559] hsr_slave_0: left promiscuous mode
[   86.759187][ T4559] hsr_slave_1: left promiscuous mode
[   86.765628][ T4559] batman_adv: batadv0: Interface deactivated: batadv_slave_0
[   86.773100][ T4559] batman_adv: batadv0: Removing interface: batadv_slave_0
[   86.782377][ T4559] batman_adv: batadv0: Interface deactivated: batadv_slave_1
[   86.790070][ T4559] batman_adv: batadv0: Removing interface: batadv_slave_1
[   86.810811][ T4559] veth1_macvtap: left promiscuous mode
[   86.816685][ T4559] veth0_macvtap: left promiscuous mode
[   86.822409][ T4559] veth1_vlan: left promiscuous mode
[   86.828558][ T4559] veth0_vlan: left promiscuous mode
[   87.103965][ T4559] team0 (unregistering): Port device team_slave_1 removed
[   87.133637][ T4559] team0 (unregistering): Port device team_slave_0 removed
[   87.695499][ T4559] netdevsim netdevsim0 netdevsim3 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
[   87.754614][ T4559] netdevsim netdevsim0 netdevsim2 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
[   87.833906][ T4559] netdevsim netdevsim0 netdevsim1 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
[   87.903519][ T4559] netdevsim netdevsim0 netdevsim0 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
[   88.019657][ T4559] bridge_slave_1: left allmulticast mode
[   88.026013][ T4559] bridge_slave_1: left promiscuous mode
[   88.031763][ T4559] bridge0: port 2(bridge_slave_1) entered disabled state
[   88.040560][ T4559] bridge_slave_0: left allmulticast mode
[   88.047223][ T4559] bridge_slave_0: left promiscuous mode
[   88.052958][ T4559] bridge0: port 1(bridge_slave_0) entered disabled state
[   88.234049][ T4559] bond0 (unregistering): (slave bond_slave_0): Releasing backup interface
[   88.244910][ T4559] bond0 (unregistering): (slave bond_slave_1): Releasing backup interface
[   88.254681][ T4559] bond0 (unregistering): Released all slaves
[   88.503276][ T4559] hsr_slave_0: left promiscuous mode
[   88.515190][ T4559] hsr_slave_1: left promiscuous mode
[   88.521144][ T4559] batman_adv: batadv0: Interface deactivated: batadv_slave_0
[   88.533055][ T4559] batman_adv: batadv0: Removing interface: batadv_slave_0
[   88.541418][ T4559] batman_adv: batadv0: Interface deactivated: batadv_slave_1
[   88.549624][ T4559] batman_adv: batadv0: Removing interface: batadv_slave_1
[   88.566813][ T4559] veth1_macvtap: left promiscuous mode
[   88.572380][ T4559] veth0_macvtap: left promiscuous mode
[   88.578459][ T4559] veth1_vlan: left promiscuous mode
[   88.583771][ T4559] veth0_vlan: left promiscuous mode
[   88.850925][ T4559] team0 (unregistering): Port device team_slave_1 removed
[   88.879924][ T4559] team0 (unregistering): Port device team_slave_0 removed


syzkaller build log:
go env (err=<nil>)
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE='auto'
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/syzkaller/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/syzkaller/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2311833903=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/syzkaller/jobs-2/linux/gopath/src/github.com/google/syzkaller/go.mod'
GOMODCACHE='/syzkaller/jobs-2/linux/gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/syzkaller/jobs-2/linux/gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/syzkaller/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'

git status (err=<nil>)
HEAD detached at 004c195c04
nothing to commit, working tree clean


tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
go list -f '{{.Stale}}' -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=004c195c04b03dc0333690d4eef6f935ab80f739 -X github.com/google/syzkaller/prog.gitRevisionDate=20260128-101947"  ./sys/syz-sysgen | grep -q false || go install -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=004c195c04b03dc0333690d4eef6f935ab80f739 -X github.com/google/syzkaller/prog.gitRevisionDate=20260128-101947"  ./sys/syz-sysgen
make .descriptions
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=004c195c04b03dc0333690d4eef6f935ab80f739 -X github.com/google/syzkaller/prog.gitRevisionDate=20260128-101947"  -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
mkdir -p ./bin/linux_amd64
g++ -o ./bin/linux_amd64/syz-executor executor/executor.cc \
	-m64 -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -Wno-stringop-overflow -Wno-array-bounds -Wno-format-overflow -Wno-unused-but-set-variable -Wno-unused-command-line-argument -static-pie -std=c++17 -I. -Iexecutor/_include   -DGOOS_linux=1 -DGOARCH_amd64=1 \
	-DHOSTGOOS_linux=1 -DGIT_REVISION=\"004c195c04b03dc0333690d4eef6f935ab80f739\"
/usr/bin/ld: /tmp/ccMi1lE0.o: in function `Connection::Connect(char const*, char const*)':
executor.cc:(.text._ZN10Connection7ConnectEPKcS1_[_ZN10Connection7ConnectEPKcS1_]+0x386): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./tools/check-syzos.sh 2>/dev/null


Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=1676e25a580000


Tested on:

commit:         0499add8 Merge tag 'kvm-x86-fixes-6.19-rc1' of https:/..
git tree:       git://git.kernel.org/pub/scm/virt/kvm/kvm.git next
kernel config:  https://syzkaller.appspot.com/x/.config?x=3aec2f7e1730a8eb
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=15dae25a580000

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
general protection fault in __unmap_hugepage_range

Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
CPU: 0 UID: 0 PID: 6527 Comm: syz.4.21 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
RIP: 0010:hstate_inode include/linux/hugetlb.h:540 [inline]
RIP: 0010:hstate_file include/linux/hugetlb.h:756 [inline]
RIP: 0010:hstate_vma include/linux/hugetlb.h:772 [inline]
RIP: 0010:__unmap_hugepage_range+0x113/0x15f0 mm/hugetlb.c:5177
Code: 48 c1 ea 03 80 3c 02 00 0f 85 dd 12 00 00 48 8b 9b 38 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 50 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cb 12 00 00 48 8b 43 50 48 89 44 24 10 48 05 a8
RSP: 0018:ffffc90003e9f700 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000200000800000
RDX: 000000000000000a RSI: ffffffff826be487 RDI: 0000000000000050
RBP: ffff88804f9ff000 R08: 0000000000000000 R09: 0000000000000003
R10: 0000000000400000 R11: 0000000000000000 R12: 0000000000000003
R13: ffff88804f9ff000 R14: 0000200000000000 R15: 0000200000800000
FS:  0000000000000000(0000) GS:ffff8881245d9000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f37b2b31000 CR3: 000000006529d000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 unmap_single_vma+0x1ef/0x240 mm/memory.c:2058
 unmap_vmas+0x218/0x470 mm/memory.c:2104
 exit_mmap+0x181/0xae0 mm/mmap.c:1277
 __mmput+0x12a/0x410 kernel/fork.c:1173
 mmput+0x67/0x80 kernel/fork.c:1196
 exit_mm kernel/exit.c:581 [inline]
 do_exit+0x78a/0x2a30 kernel/exit.c:959
 do_group_exit+0xd5/0x2a0 kernel/exit.c:1112
 get_signal+0x1ec7/0x21e0 kernel/signal.c:3034
 arch_do_signal_or_restart+0x91/0x7a0 arch/x86/kernel/signal.c:337
 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
 exit_to_user_mode_loop+0x86/0x4b0 kernel/entry/common.c:75
 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
 syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
 syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
 do_syscall_64+0x4fe/0xf80 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1b38f9aeb9
Code: Unable to access opcode bytes at 0x7f1b38f9ae8f.
RSP: 002b:00007f1b39d820e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: 0000000000000001 RBX: 00007f1b39215fa8 RCX: 00007f1b38f9aeb9
RDX: 00000000000f4240 RSI: 0000000000000081 RDI: 00007f1b39215fac
RBP: 00007f1b39215fa0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000246 R12: 0000000000000000
R13: 00007f1b39216038 R14: 00007ffe5bb4b350 R15: 00007ffe5bb4b438
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:hstate_inode include/linux/hugetlb.h:540 [inline]
RIP: 0010:hstate_file include/linux/hugetlb.h:756 [inline]
RIP: 0010:hstate_vma include/linux/hugetlb.h:772 [inline]
RIP: 0010:__unmap_hugepage_range+0x113/0x15f0 mm/hugetlb.c:5177
Code: 48 c1 ea 03 80 3c 02 00 0f 85 dd 12 00 00 48 8b 9b 38 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 50 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cb 12 00 00 48 8b 43 50 48 89 44 24 10 48 05 a8
RSP: 0018:ffffc90003e9f700 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000200000800000
RDX: 000000000000000a RSI: ffffffff826be487 RDI: 0000000000000050
RBP: ffff88804f9ff000 R08: 0000000000000000 R09: 0000000000000003
R10: 0000000000400000 R11: 0000000000000000 R12: 0000000000000003
R13: ffff88804f9ff000 R14: 0000200000000000 R15: 0000200000800000
FS:  0000000000000000(0000) GS:ffff8881246d9000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6a9d71f286 CR3: 0000000060f0e000 CR4: 00000000003526f0
----------------
Code disassembly (best guess):
   0:	48 c1 ea 03          	shr    $0x3,%rdx
   4:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1)
   8:	0f 85 dd 12 00 00    	jne    0x12eb
   e:	48 8b 9b 38 06 00 00 	mov    0x638(%rbx),%rbx
  15:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  1c:	fc ff df
  1f:	48 8d 7b 50          	lea    0x50(%rbx),%rdi
  23:	48 89 fa             	mov    %rdi,%rdx
  26:	48 c1 ea 03          	shr    $0x3,%rdx
* 2a:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
  2e:	0f 85 cb 12 00 00    	jne    0x12ff
  34:	48 8b 43 50          	mov    0x50(%rbx),%rax
  38:	48 89 44 24 10       	mov    %rax,0x10(%rsp)
  3d:	48                   	rex.W
  3e:	05                   	.byte 0x5
  3f:	a8                   	.byte 0xa8


Tested on:

commit:         05f7e89a Linux 6.19
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=125217fa580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=171d865a580000

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com

Tested on:

commit:         05f7e89a Linux 6.19
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14d0d402580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=12dd865a580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com

Tested on:

commit:         05f7e89a Linux 6.19
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12b26a52580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1fac0919970b671
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=15a0f65a580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [kvm?] WARNING in kvm_gmem_fault_user_mapping

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com

Tested on:

commit:         cee73b1e Merge tag 'riscv-for-linus-7.0-mw1' of git://..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=121b2994580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=3c6097f9f42b05eb
dashboard link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=13e342aa580000

Note: testing is done by a robot and is best-effort only.