Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/10/20 3:11 PM, Jason Gunthorpe wrote:
On Thu, Sep 10, 2020 at 02:22:37PM -0700, John Hubbard wrote:

Or am I way off here, and it really is possible (aside from the current
s390 situation) to observe something that "is no longer a page table"?

Yes, that is the issue. Remember there is no locking for GUP
fast. While a page table cannot be freed there is nothing preventing
the page table entry from being concurrently modified.


OK, then we are saying the same thing after all, good.

Without the stack variable it looks like this:

        pud_t pud = READ_ONCE(*pudp);
        if (!pud_present(pud))
             return
        pmd_offset(pudp, address);

And pmd_offset() expands to

     return (pmd_t *)pud_page_vaddr(*pud) + pmd_index(address);

Between the READ_ONCE(*pudp) and (*pud) inside pmd_offset() the value
of *pud can change, eg to !pud_present.

Then pud_page_vaddr(*pud) will crash. It is not use after free, it
is using data that has not been validated.


Right, that matches what I had in mind, too: you can still have a problem
even though you're in the same page table. I just wanted to confirm that
there's not some odd way to launch out into completely non-page-table
memory.


thanks,
--
John Hubbard
NVIDIA



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux