linux-kernel - Re: [PATCH v2 1/1] userfaultfd: fix a crash when UFFDIO

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: <CAJuCfpGpEOaKdqpqTpfbw1cdHEEWhiu6KRFQFWaM-AKODiDFcg@mail.gmail.com>
Date: Wed, 6 Aug 2025 08:06:04 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Peter Xu <peterx@...hat.com>
Cc: David Hildenbrand <david@...hat.com>, akpm@...ux-foundation.org, aarcange@...hat.com, 
	lokeshgidra@...gle.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	syzbot+b446dbe27035ef6bd6c2@...kaller.appspotmail.com, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/1] userfaultfd: fix a crash when UFFDIO_MOVE handles
 a THP hole

On Tue, Aug 5, 2025 at 5:41 PM Peter Xu <peterx@...hat.com> wrote:
>
> On Tue, Aug 05, 2025 at 04:41:18PM -0700, Suren Baghdasaryan wrote:
> > Ok, I let the reproducer run for half a day and it did not hit this
> > case, so I must have done something wrong during my initial
> > investigation. Sorry for the confusion. I could have sworn that I saw
> > this case but now it just does not happen.
>
> I'm wildly guessing you might have hit the numa balancing bug I mentioned,
> that might explain what you mentioned previously on the testing results.
> It might just be tricky to reproduce:
>
>   - We'll need a valid THP (pmd) first in the MOVE source region
>
>   - THP needs to be selected by numa balancing for a check (marking
>     prot_none)
>
>   - (before any further access..) UFFDIO_MOVE needs to happen on top trying
>     to move the whole THP being marked as prot_none.
>
> AFAICT, task_numa_work() is the only place that can mark the THP, and when
> it happens, should see change_huge_pmd(cp_flags=MM_CP_PROT_NUMA) and then
> returns with HPAGE_PMD_NR.
>
> [sorry I am still pretty occupied with other things.  I can try to reproduce
>  together with you after I get more time back]
>
> > With migration entry being the only case that leads to that
> > pmd_folio(), the only check we need to add is the "if
> > (pmd_present(*src_pmd))" before pmd_folio(). Would you like me to
> > check anything else or should I go ahead and post that fix?
>
> We could fix the migration entry first, then if any of us can reproduce the
> above numa balancing issue then it can be a 2nd patch on top.
>
> After all, so far we didn't yet prove it, either some unreproduceable test,
> or pure code analysis.  Meanwhile it might also be cleaner if we have one
> patch fix one issue, rather than having one patch fix two bugs.
>
> What do you think?

Agree, that seems reasonable. I'll post the new fix today.
Thanks,
Suren.

>
> Thanks,
>
> --
> Peter Xu
>