syzbot ci has tested the following series [v1] mm: remove nth_page() https://lore.kernel.org/all/20250821200701.1329277-1-da...@redhat.com * [PATCH RFC 01/35] mm: stop making SPARSEMEM_VMEMMAP user-selectable * [PATCH RFC 02/35] arm64: Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP" * [PATCH RFC 03/35] s390/Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP" * [PATCH RFC 04/35] x86/Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP" * [PATCH RFC 05/35] wireguard: selftests: remove CONFIG_SPARSEMEM_VMEMMAP=y from qemu kernel config * [PATCH RFC 06/35] mm/page_alloc: reject unreasonable folio/compound page sizes in alloc_contig_range_noprof() * [PATCH RFC 07/35] mm/memremap: reject unreasonable folio/compound page sizes in memremap_pages() * [PATCH RFC 08/35] mm/hugetlb: check for unreasonable folio sizes when registering hstate * [PATCH RFC 09/35] mm/mm_init: make memmap_init_compound() look more like prep_compound_page() * [PATCH RFC 10/35] mm/hugetlb: cleanup hugetlb_folio_init_tail_vmemmap() * [PATCH RFC 11/35] mm: sanity-check maximum folio size in folio_set_order() * [PATCH RFC 12/35] mm: limit folio/compound page sizes in problematic kernel configs * [PATCH RFC 13/35] mm: simplify folio_page() and folio_page_idx() * [PATCH RFC 14/35] mm/mm/percpu-km: drop nth_page() usage within single allocation * [PATCH RFC 15/35] fs: hugetlbfs: remove nth_page() usage within folio in adjust_range_hwpoison() * [PATCH RFC 16/35] mm/pagewalk: drop nth_page() usage within folio in folio_walk_start() * [PATCH RFC 17/35] mm/gup: drop nth_page() usage within folio when recording subpages * [PATCH RFC 18/35] io_uring/zcrx: remove "struct io_copy_cache" and one nth_page() usage * [PATCH RFC 19/35] io_uring/zcrx: remove nth_page() usage within folio * [PATCH RFC 20/35] mips: mm: convert __flush_dcache_pages() to __flush_dcache_folio_pages() * [PATCH RFC 21/35] mm/cma: refuse handing out non-contiguous page ranges * [PATCH RFC 22/35] dma-remap: drop nth_page() in dma_common_contiguous_remap() * [PATCH RFC 23/35] scatterlist: disallow non-contigous page ranges in a single SG entry * [PATCH RFC 24/35] ata: libata-eh: drop nth_page() usage within SG entry * [PATCH RFC 25/35] drm/i915/gem: drop nth_page() usage within SG entry * [PATCH RFC 26/35] mspro_block: drop nth_page() usage within SG entry * [PATCH RFC 27/35] memstick: drop nth_page() usage within SG entry * [PATCH RFC 28/35] mmc: drop nth_page() usage within SG entry * [PATCH RFC 29/35] scsi: core: drop nth_page() usage within SG entry * [PATCH RFC 30/35] vfio/pci: drop nth_page() usage within SG entry * [PATCH RFC 31/35] crypto: remove nth_page() usage within SG entry * [PATCH RFC 32/35] mm/gup: drop nth_page() usage in unpin_user_page_range_dirty_lock() * [PATCH RFC 33/35] kfence: drop nth_page() usage * [PATCH RFC 34/35] block: update comment of "struct bio_vec" regarding nth_page() * [PATCH RFC 35/35] mm: remove nth_page()
and found the following issue: general protection fault in kfence_guarded_alloc Full report is available here: https://ci.syzbot.org/series/f6f0aea1-9616-4675-8c80-f9b59ba3211c *** general protection fault in kfence_guarded_alloc tree: net-next URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git base: da114122b83149d1f1db0586b1d67947b651aa20 arch: amd64 compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7 config: https://ci.syzbot.org/builds/705b7862-eb10-40bd-a4cf-4820b4912466/config smpboot: CPU0: Intel(R) Xeon(R) CPU @ 2.80GHz (family: 0x6, model: 0x55, stepping: 0x7) Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:kfence_guarded_alloc+0x643/0xc70 Code: 41 c1 e5 18 bf 00 00 00 f5 44 89 ee e8 a6 67 9c ff 45 31 f6 41 81 fd 00 00 00 f5 4c 0f 44 f3 49 8d 7e 08 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 74 05 e8 f1 cb ff ff 4c 8b 6c 24 18 4d 89 6e 08 49 RSP: 0000:ffffc90000047740 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffea0004d90080 RCX: 0000000000000000 RDX: ffff88801c2e8000 RSI: 00000000ff000000 RDI: 0000000000000008 RBP: ffffc90000047850 R08: ffffffff99b2201b R09: 1ffffffff3364403 R10: dffffc0000000000 R11: fffffbfff3364404 R12: dffffc0000000000 R13: 00000000ff000000 R14: 0000000000000000 R15: ffff88813fec7068 FS: 0000000000000000(0000) GS:ffff8880b861c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff88813ffff000 CR3: 000000000df36000 CR4: 0000000000350ef0 Call Trace: <TASK> __kfence_alloc+0x385/0x3b0 __kmalloc_noprof+0x440/0x4f0 __alloc_workqueue+0x103/0x1b70 alloc_workqueue_noprof+0xd4/0x210 init_mm_internals+0x17/0x140 kernel_init_freeable+0x307/0x4b0 kernel_init+0x1d/0x1d0 ret_from_fork+0x3f9/0x770 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:kfence_guarded_alloc+0x643/0xc70 Code: 41 c1 e5 18 bf 00 00 00 f5 44 89 ee e8 a6 67 9c ff 45 31 f6 41 81 fd 00 00 00 f5 4c 0f 44 f3 49 8d 7e 08 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 74 05 e8 f1 cb ff ff 4c 8b 6c 24 18 4d 89 6e 08 49 RSP: 0000:ffffc90000047740 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffea0004d90080 RCX: 0000000000000000 RDX: ffff88801c2e8000 RSI: 00000000ff000000 RDI: 0000000000000008 RBP: ffffc90000047850 R08: ffffffff99b2201b R09: 1ffffffff3364403 R10: dffffc0000000000 R11: fffffbfff3364404 R12: dffffc0000000000 R13: 00000000ff000000 R14: 0000000000000000 R15: ffff88813fec7068 FS: 0000000000000000(0000) GS:ffff8880b861c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff88813ffff000 CR3: 000000000df36000 CR4: 0000000000350ef0 *** If these findings have caused you to resend the series or submit a separate fix, please add the following tag to your commit message: Tested-by: syz...@syzkaller.appspotmail.com --- This report is generated by a bot. It may contain errors. syzbot ci engineers can be reached at syzkal...@googlegroups.com.
