Thread (62 messages) 62 messages, 11 authors, 2020-09-15

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

From: Alexander Gordeev <agordeev@linux.ibm.com>
Date: 2020-09-11 12:36:53
Also in: linux-arch, linux-arm-kernel, linux-mm, linux-s390, linux-um, lkml, sparclinux

On Thu, Sep 10, 2020 at 07:11:16PM -0300, Jason Gunthorpe wrote:
On Thu, Sep 10, 2020 at 02:22:37PM -0700, John Hubbard wrote:
quoted
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.

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.
One thing I ask myself and it is probably a good moment to wonder.

What if the entry is still pud_present, but got remapped after
READ_ONCE(*pudp)? IOW, it is still valid, but points elsewhere?
Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help