On Wed, Feb 5, 2025 at 4:47 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > * Jann Horn <jannh@xxxxxxxxxx> [250205 10:00]: > > The comments in the VMA flags code incorrectly assume that no > > concurrency is possible here; and I think the comment in > > mprotect_fixup() about protection by the mmap_lock has also been kinda > > wrong since the beginning of git history. > > > > The VM_LOCKED check in the migration code was added by Hugh in commit > > b74355078b655, but that's just one example syzbot stumbled over; we > > have similar racy vm_flags reads through the rmap on other paths like: > > > > unmap_mapping_range_tree -> unmap_mapping_range_vma -> > > zap_page_range_single -> unmap_single_vma -> unmap_page_range -> ... > > -> zap_pte_range -> zap_present_ptes -> vm_normal_page > > I think we need a list of vm_area_struct parts that are OK to access > without the read/write/vma lock. It seems flags is not one of those as > it could be racy. We do have this big table in these nice docs that Lorenzo spent quite some effort on: https://kernel.org/doc/html/latest/mm/process_addrs.html#vma-fields Though that does not currently call out this possible concurrency of vm_flags.
