Re: CVS commit: src/sys/uvm
On Fri, May 19, 2017 at 03:30:19PM +, 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 sounds like something that won't be good if not atomic, but I don't know enough to tell if it can be abused. Thanks.
Re: CVS commit: src/sys/uvm
On Fri, May 19, 2017 at 04:14:03PM +, co...@sdf.org wrote: > On Fri, May 19, 2017 at 03:30:19PM +, 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. Joerg
Re: CVS commit: src/sys/uvm
In article <20170519162231.ga3...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Fri, May 19, 2017 at 04:14:03PM +, co...@sdf.org wrote: >> On Fri, May 19, 2017 at 03:30:19PM +, 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
Re: CVS commit: src/sys/uvm
On 19.05.2017 17:30, 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. > > > To generate a diff of this commit: > cvs rdiff -u -r1.346 -r1.347 src/sys/uvm/uvm_map.c > cvs rdiff -u -r1.164 -r1.165 src/sys/uvm/uvm_mmap.c > UVM broke after this commit. I cannot build packages due to random memory corruptions. Processes die / files (at least executables) contain trash. There are also users on IRC reporting the same behavior. signature.asc Description: OpenPGP digital signature