Re: [syzbot] [mm?] general protection fault in zap_huge_pmd

[Lorenzo Stoakes (Oracle)]

On Wed, Mar 18, 2026 at 10:54:16PM +0100, Aleksandr Nogikh wrote:
> On Wed, Mar 18, 2026 at 6:26 PM 'Lorenzo Stoakes (Oracle)' via
> syzkaller-bugs <syzkaller-bugs@xxxxxxxxxxxxxxxx> wrote:
> >
> > +cc Mike for uffd, Harry for fix that also resolves this, see below
> >
> > On Wed, Mar 18, 2026 at 08:03:22AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:    b84a0ebe421c Add linux-next specific files for 20260313
> >
> > For some reason I have to git pull --tags to get this... commit hash locally?
> > Strange.
> >
> > > git tree:       linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=119ddd52580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=e7280ad1f68b2dce
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=de14f7701c22477db718
> > > compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=173b44da580000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1537b8da580000
> >
> > @SYZKALLER guys:
> >
> > Note: the repro is incorrectly labelling;
> >
> >   //  ioctl$UFFDIO_CONTINUE arguments: [
> >   //    fd: fd_uffd (resource)
> >   //    cmd: const = 0xc020aa08 (4 bytes)
> >
> > as UFFDIO_CONTINUE (0x7), it's actually UFFDIO_POISION (0x8) as you can see
> > from least-significant byte.
>
> Hmmm, that shouldn't have happened. Syzkaller normally tries to avoid
> mutating one ioctl into another.
> I've filed https://github.com/google/syzkaller/issues/6950.
>
> >
> > It's also stating things like mmap flags wrong e.g.:
> >
> >       /*flags=MAP_UNINITIALIZED|MAP_POPULATE|MAP_NORESERVE|MAP_NONBLOCK|MAP_HUGETLB|0x8c4b815a506002b2*/
> >       0x8c4b815a5465c2b2ul,
> >
> > AT LEAST MAKE THE NUMBERS MATCH :) this doesn't help with debugging.
>
> MAP_UNINITIALIZED = 0x4000000
> MAP_POPULATE = 0x8000
> MAP_NORESERVE = 0x4000
> MAP_NONBLOCK = 0x10000
> MAP_HUGETLB = 0x40000
> rest = 0x8c4b815a506002b2
> print(hex(MAP_UNINITIALIZED + MAP_POPULATE + MAP_NORESERVE +
> MAP_HUGETLB + rest))
>
> gives me exactly 0x8c4b815a5465c2b2ul. What was the problem here? :)

ugh, yeah sorry I misread that:

/*flags=MAP_UNINITIALIZED|MAP_POPULATE|MAP_NORESERVE|MAP_NONBLOCK|MAP_HUGETLB|0x8c4b815a506002b2*/
                                                                              ^^^^^^^^^^^^^^^^^^

I read it that 0x8c4... value being the value that the preceding flags come
to but obviously |x|y|z|...|<some hex val> means it's additional garbage right?

But it's not really decoding properly here at all:

Writing a bit of code to decode, 0x8c4b815a5465c2b2 becomes:

MAP_HUGE_2MB|MAP_HUGETLB|MAP_NONBLOCK|MAP_POPULATE|MAP_NORESERVE|MAP_ANONYMOUS|MAP_FIXED|MAP_PRIVATE|unknown=0x8c4b815a00600280

So I do think that your algorithm could do with some tweaking here :)
especially MAP_FIXED, as it wasn't clear as to whether the addr passed was
a hint or not.

(MAP_UNINITIALIZED overlapping with hugetlb sizing flags is annoying, as is
how that's encoded too.)

(I put the code at https://github.com/ljskernel/mm/tree/main/tools - it may
or may not be buggy :))

>
> >
> > AI hallucinations?
> >
> > It also never returns with an error if a syscall doesn't work which means the
> > repro can run 'ok' but actually be failing on something, this really slows down repro'ing.
>
> That's an interesting point. There will be corner cases where a
> syscall is expected to fail or may start failing after N iterations
> and that's fine, but the idea is totally worth exploring further.

Yeah for sure, but at least outputting the information would be useful, so
you could have the same exact behaviour just with more stderr output?

>
> >
> > Maybe hard, but be good to figure out maintainers based on the stuff the repro
> > uses uffd -> uffd entry in MAINTAINERS :)
>
> It's easily doable, but there's a problem: uffd maintainers will be
> CC'd whenever uffd is used in a reproducer, which may not always mean
> that it truly caused the crash. We do minimize reproducers, but there
> always remain some weird cases where unrelated syscalls persist e.g.
> only to force some specific timings or to get specific file handle
> numbers.

I don't want to speak for Mike but will anyway ;) [speak up Mike if you
disagree :P] - I think it'd be fine to do that and just let it cc- some
people inappropriately sometimes.

Or you could narrow it down by first making sure it's an mm bug and THEN if
uffd in repro include uffd people?

>
> That's why we mostly rely on stack traces to identify subsystems.

Right yeah.

Cheers, Lorenzo