seems to depend on 2ea7ff1e39cbe (mm/hugetlb: fix race condition of uffd missing/minor handling) for hugetlb_pte_stable().

which we do not have anywhere so far.

(In reply to Robert Frohl from comment #1)
> seems to depend on 2ea7ff1e39cbe (mm/hugetlb: fix race condition of uffd
> missing/minor handling) for hugetlb_pte_stable().
> 
> which we do not have anywhere so far.

Thanks for pointing out 2ea7ff1e39cbe. The important part of the cover letter is this:
"
    Currently akpm mm-unstable fails with uffd hugetlb private mapping test
    randomly on a write check.
    
    The initial bisection of that points to the recent pmd unshare series, but
    it turns out there's no direction relationship with the series but only
    some timing change caused the race to start trigger.
"

So this needs a further investigation because it is possible the problem predates pmd unshare changes. Oscar, could you have a look please?

@kernel-bugs: Could someone help with assessing this ? I would rate 5.3 and 5.14 as affected from the code side. 

But as the commit is only talking about a 'migration
race condition', I am not sure if we want to introduce the other commit (i.e. 2ea7ff1e39cbe) or even the full series (not sure what would be needed). 

(posting this anyway even though Michal Hocko was faster :) )

So, let me see if I get this straight.
We have [1], which is part of a larger series "Patch series "mm/hugetlb: Fix selftest failures with write check" (2ea7ff1e39cbe3753d3c649beb70f2cf861dca75),
which seems to fix a race condition that can be triggered after recent changes on pmd unshare "Patch series hugetlb: Use new vma lock for huge pmd sharing synchronization", but there is no direct correlation, so it might be that the pmd unshare series just made de race window larger.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f9bf6c03eca1077cae8de0e6d86427656fa42a9b

(In reply to Oscar Salvador from comment #4)
> So, let me see if I get this straight.
> We have [1], which is part of a larger series "Patch series "mm/hugetlb: Fix
> selftest failures with write check"
> (2ea7ff1e39cbe3753d3c649beb70f2cf861dca75),
> which seems to fix a race condition that can be triggered after recent
> changes on pmd unshare "Patch series hugetlb: Use new vma lock for huge pmd
> sharing synchronization", but there is no direct correlation, so it might be
> that the pmd unshare series just made de race window larger.

This is my understanding as well. I would recommend talking to Mike (upstream) and see whether the real issue can be identified in the upstream code. Then we will know which kernels might be affected as well.

I asked Mike about this, the following is his response:

"
I am a bit surprised that change got classified as a CVE.  A little more
information on the actual race is in this email message.
https://lore.kernel.org/linux-mm/YztYC+2jalrsxKDm@monkey/

Prior to the new series which uses a new vma lock for pmd synchronizatrion,
the i_mmap_sema was used for pmd synchronizatrion.  It was taken in read mode
during page fault processing.  Since it needs to be held in write mode during
hugetlb_change_protection, it prevented faults from racing with changes in
pte protection.  Note that preventing this race via the use of i_mmap_sema
was not not intentional.  It was rather a side effect of using the lock for
pmd sharing.

Commit c0d0381ade79 "hugetlbfs: use i_mmap_rwsem for more pmd sharing
synchronization" is when the code to use i_mmap_rwsem was introduced.  So,
I would not expect this issue to be exposed with this commit in place.  It
was reverted when the new hugetlb vma_lock was introduced.

Also, note that the userfaultfd write protect code did not exist when commit
c0d0381ade79 was added.  So, I do not believe this specific issue of faults
racing with uffd missing/minor handling ever existed in 'released' kernels.
The race was exposed and fixed in the v6.1 merge window.

In looking at the potential for a different race before c0d0381ade79, I do
not think that was possible.  Only uffd missing was supported at that time.
hugetlb_change_protection could have been called and raced with page faults.
However, hugetlb_change_protection did nothing for non-present or none ptes
at the time.  So, I would not expect the race to be triggered.

That is a long way of saying, IMO there never was an exposure except in
development code.  Peter may have a different opinion."

From this, I take that prior to the last changes in pmd unsharing, the race did not
exist, merely for two reasons 1) the code that allowed this to happen did not
exist and 2) in case it did, the way we were handling i_mmap_rwsem would have prevented that.

I guess the important note is:

"Also, note that the userfaultfd write protect code did not exist when commit
c0d0381ade79 was added.  So, I do not believe this specific issue of faults
racing with uffd missing/minor handling ever existed in 'released' kernels.
The race was exposed and fixed in the v6.1 merge window."

So, all in all, and unless I am missing something, I do not think we are affected.

There were a lot of these CVEs in the past days (all that contain a VDB-NNNNNN identifier in the first comment). They looked somewhat automated to me.

There were definitely some for iproute2 where I opened bugs for Michal Kubeček, that were not very helpful. Judging this correctly for the kernel is for harder though.

If you have complaints with any of them let me know, I would start the dispute process.

filed a CVE Dispute request with cross referencing this bugzilla and the kernel.org link.

The issue was accepted as disputed by the reporting CNA.


SUSE will not releases fixes for this.