This is an old problem, first reported in December 2001. 
The test case is a multithreaded application doing a large number of 
malloc()/free().

When running on a 16k page size kernel, the current algorithm creates
a temporary page, copies data to that page, does a new mmap and copies
back subpages from the temporary page. This leaves a window of opportunity
open for another thread to unmap or change the data in such a way that
the new page has stale data.

A patch was proposed which tries to do away with copying if the old page
was writable.  The patch was rejected because it could corrupt data in
the MAP_SHARED case.

https://external-lists.vasoftware.com/archives/linux-ia64/2001-December/002549.html
https://external-lists.vasoftware.com/archives/linux-ia64/2001-December/002550.html

Since we found that most of the apps which ran into this problem were
dealing with pages where the old data and new data are both anonymous,
I reworked the above patch in such a way that we don't optimize for
the MAP_SHARED case. Infact, the only case that we optimize is the case
where the old and new mapping are both anonymous.