In article <20170519162231.ga3...@britannica.bec.de>, Joerg Sonnenberger <jo...@bec.de> wrote: >On Fri, May 19, 2017 at 04:14:03PM +0000, co...@sdf.org wrote: >> On Fri, May 19, 2017 at 03:30:19PM +0000, Chuck Silvers wrote: >> > Module Name: src >> > Committed By: chs >> > Date: Fri May 19 15:30:19 UTC 2017 >> > >> > Modified Files: >> > src/sys/uvm: uvm_map.c uvm_mmap.c >> > >> > Log Message: >> > make MAP_FIXED mapping operations atomic. fixes PR 52239. >> > previously, unmapping any entries being replaced was done separately >> > from entering the new mapping, which allowed another thread doing >> > a non-MAP_FIXED mapping to allocate the range out from under the >> > MAP_FIXED thread. >> >> Does that have security ramifications? > >It's a form of memory corruption under races. We should issue a SN for >it, but I don't think MAP_FIXED is that popular in general. The case in >jemalloc is now better served by using mprotect and PROT_MPROTECT, btw.
We should pull it up to -7 at least... christos
