linux-kernel - Re: [syzbot] [mm?] WARNING in do_wp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ec2c31e4-f7f2-4ec0-bbfe-e6d6e080429f@redhat.com>
Date: Sun, 13 Apr 2025 22:20:17 +0200
From: David Hildenbrand <david@...hat.com>
To: syzbot <syzbot+5e8feb543ca8e12e0ede@...kaller.appspotmail.com>,
 akpm@...ux-foundation.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [mm?] WARNING in do_wp_page

On 12.04.25 20:46, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:

Related to my recent changes

> 
> HEAD commit:    0af2f6be1b42 Linux 6.15-rc1
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1766323f980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=f175b153b655dbb3

CONFIG_ARCH_WANTS_THP_SWAP=y
CONFIG_MM_ID=y
CONFIG_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
# CONFIG_TRANSPARENT_HUGEPAGE_NEVER is not set
CONFIG_THP_SWAP=y
CONFIG_READ_ONLY_THP_FOR_FS=y
# CONFIG_NO_PAGE_MAPCOUNT is not set
CONFIG_PAGE_MAPCOUNT=y

> dashboard link: https://syzkaller.appspot.com/bug?extid=5e8feb543ca8e12e0ede
> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/f1d71d1bf77d/disk-0af2f6be.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7f1638f065da/vmlinux-0af2f6be.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/9b3e49834705/bzImage-0af2f6be.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5e8feb543ca8e12e0ede@...kaller.appspotmail.com
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 7165 at mm/memory.c:3738 __wp_can_reuse_large_anon_folio mm/memory.c:3738 [inline]

VM_WARN_ON_ONCE(folio_entire_mapcount(folio));

Which is rather unexpected. I know we had a scenario (remapping a THP?) 
where we would have a PMD mapping and a PTE mapping of an exclusive anon 
folio for a very short time. But, IIRC locking should make sure that 
that cannot be observed by some other page table walker.

Unfortunately o reproducer. I'll do some digging ...


> WARNING: CPU: 0 PID: 7165 at mm/memory.c:3738 wp_can_reuse_anon_folio mm/memory.c:3788 [inline]
> WARNING: CPU: 0 PID: 7165 at mm/memory.c:3738 do_wp_page+0x4c62/0x59f0 mm/memory.c:3918
> Modules linked in:
> CPU: 0 UID: 0 PID: 7165 Comm: syz.3.280 Not tainted 6.15.0-rc1-syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
> RIP: 0010:__wp_can_reuse_large_anon_folio mm/memory.c:3738 [inline]
> RIP: 0010:wp_can_reuse_anon_folio mm/memory.c:3788 [inline]
> RIP: 0010:do_wp_page+0x4c62/0x59f0 mm/memory.c:3918
> Code: 48 89 ef e8 50 c3 ea ff e9 62 b8 ff ff e8 c6 e0 b4 ff 48 c7 c6 20 43 9b 8b 4c 89 e7 e8 f7 a0 fc ff 90 0f 0b e8 af e0 b4 ff 90 <0f> 0b 90 e9 df ed ff ff e8 a1 e0 b4 ff 48 c7 c6 60 46 9b 8b 48 89
> RSP: 0018:ffffc900039f77e0 EFLAGS: 00010287
> RAX: 0000000000041ec0 RBX: ffffc900039f7a00 RCX: ffffc9000d0c6000
> RDX: 0000000000080000 RSI: ffffffff82065c61 RDI: 0000000000000005
> RBP: ffffea0001320000 R08: 0000000000000005 R09: 00000000ffffffff
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888012935dc0
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
> FS:  00007f57215806c0(0000) GS:ffff8881249b9000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000020000001e000 CR3: 000000006cd88000 CR4: 0000000000350ef0
> Call Trace:
>   <TASK>
>   handle_pte_fault mm/memory.c:6013 [inline]
>   __handle_mm_fault+0x1ada/0x2a40 mm/memory.c:6140
>   handle_mm_fault+0x3fe/0xad0 mm/memory.c:6309
>   faultin_page mm/gup.c:1193 [inline]
>   __get_user_pages+0x771/0x36f0 mm/gup.c:1491
>   populate_vma_page_range+0x278/0x3a0 mm/gup.c:1929
>   __mm_populate+0x1d8/0x380 mm/gup.c:2032
>   do_mlock+0x448/0x810 mm/mlock.c:655

During do_mlock() we should be holding the mmap lock in write mode I 
assume once we reach do_wp_page.

-- 
Cheers,

David / dhildenb