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

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: <ZvRBYpCrSZj9YZoF@x1n>
Date: Wed, 25 Sep 2024 12:59:14 -0400
From: Peter Xu <peterx@...hat.com>
To: David Hildenbrand <david@...hat.com>
Cc: syzbot <syzbot+bf2c35fa302ebe3c7471@...kaller.appspotmail.com>,
	akpm@...ux-foundation.org, bp@...en8.de,
	dave.hansen@...ux.intel.com, hpa@...or.com, jgg@...pe.ca,
	leitao@...ian.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	mingo@...hat.com, rppt@...nel.org, syzkaller-bugs@...glegroups.com,
	tglx@...utronix.de, x86@...nel.org
Subject: Re: [syzbot] [mm?] WARNING in copy_huge_pmd

On Tue, Sep 24, 2024 at 04:45:00PM +0200, David Hildenbrand wrote:
> On 23.09.24 14:18, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
> > git tree:       upstream
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=e851828834875d6f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
> > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12773080580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000
> > 
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz
> > 
> > The issue was bisected to:
> > 
> > commit 75182022a0439788415b2dd1db3086e07aa506f7
> > Author: Peter Xu <peterx@...hat.com>
> > Date:   Mon Aug 26 20:43:51 2024 +0000
> > 
> >      mm/x86: support large pfn mappings
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+bf2c35fa302ebe3c7471@...kaller.appspotmail.com
> > Fixes: 75182022a043 ("mm/x86: support large pfn mappings")
> > 
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
> 
> This is the
> 
> VM_WARN_ON_ONCE(is_cow_mapping(src_vma->vm_flags) && pmd_write(pmd))
> 
> So we have a special-marked PMD in a COW mapping.
> 
> The reproducer seems to involve fuse, but not sure if that makes a
> difference here.

That chunk of code seems to be there only making sure the test won't get
blocked due to any fused based fs being stuck, via writting to the "abort"
file:

      snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort",
               ent->d_name);
      int fd = open(abort, O_WRONLY);
      if (fd == -1) {
        continue;
      }
      if (write(fd, abort, 1) < 0) {
      }
      close(fd);

So far looks not relevant to this issue indeed.

Unfortunately I cannot reproduce it even with the reproducer.  So this one
is a bit tricky..

What confuses me yet is how that special bit is set, if it's only used so
far with vfio-pci, and this test doesn't seem to have it involved.

The test keeps invoking processes, then threads, doing concurrent accesses
over a few stuff (madvise, mremap, migrate_pages, munmap, etc.) on the
pre-mapped areas, but none of them seem to create new memory that can
provide hint on how special bit can start to occur.

I wonder if some of these operations can race in a way that mm can wrongly
create the special bit (alone with it being writable).. and then it could
be a historical bug, only captured by this patchset due to the newly added
WARN_ON_ONCE somehow, then it could mean that it's not the WRITE bit that
is not intended, but the SPECIAL bit altogether.

Thanks,

-- 
Peter Xu