Per https://www.openwall.com/lists/oss-security/2018/09/18/4:

A potential local priviledge escalation bug was reported in the vmacache code dealing with 32-bit sequence number overflows, introduced in v3.16 by 6b4ebc3a9078 (mm,vmacache: optimize overflow system-wide flushing). The change introduces a "fastpath" which skips the invalidation on overflows for single threads (mm_users == 1), which can lead to a use-after-free. As reported:
`
 [A starts as a singlethreaded process]
A: create mappings X and Y (in separate memory areas far away from other allocations)
A: perform repeated invalidations until current->mm->vmacache_seqnum==0xffffffff and current->vmacache.seqnum==0xfffffffe
A: dereference an address in mapping Y that is not paged in (thereby populating A's VMA cache with Y at seqnum 0xffffffff)
A: unmap mapping X (thereby bumping current->mm->vmacache_seqnum to 0)
A: without any more find_vma() calls (which could happen e.g. via pagefaults), create a thread B
B: perform repeated invalidations until current->mm->vmacache_seqnum==0xfffffffe
B: unmap mapping Y (thereby bumping  current->mm->vmacache_seqnum to 0xffffffff)
A: dereference an address in the freed mapping Y (or any address that isn't present in the pagetables and doesn't correspond to a valid VMA cache entry)

This is fixed in 7a9cdebdcc17 (mm: get rid of vmacache_flush_all() entirely), by converting it to a 64-bit counter and not dealing with overflows anymore; which also makes the code simpler and removes rarely-run code in core kernel paths.

So a win-win altogether.

----------------------

We're vulnerable per version information (haven't checked the code).

IIUC, this allows to access a memory page that the process no longer owns? If so, likely allows privilege escalation or kernel code execution. Over to zsm@ for further triage and figuring out patch strategy.