summaryrefslogtreecommitdiff
path: root/fs/proc/array.c
diff options
context:
space:
mode:
authorOleg Nesterov <oleg@tv-sign.ru>2004-08-30 20:34:10 -0700
committerLinus Torvalds <torvalds@ppc970.osdl.org>2004-08-30 20:34:10 -0700
commitc3dfa7121a1aa80eec3f9f662bd91ecc93310c9b (patch)
tree77038d3fd2324f323a1c43d1b07a31ea6a2b9a09 /fs/proc/array.c
parentec081b118e6c9a77912493959aea07bdfa15f05a (diff)
[PATCH] hugetlbfs private mappings
Hugetlbfs silently coerce private mappings of hugetlb files into shared ones. So private writable mapping has MAP_SHARED semantics. I think, such mappings should be disallowed. First, such behavior allows open hugetlbfs file O_RDONLY, and overwrite it via mmap(PROT_READ|PROT_WRITE, MAP_PRIVATE), so it is security bug. Second, private writable mmap() should fail just because kernel does not support this. I belisve, it is ok to allow private readonly hugetlb mappings, sys_mprotect() does not work with hugetlb vmas. There is another problem. Hugetlb mapping is always prefaulted, pages allocated at mmap() time. So even readonly mapping allows to enlarge the size of the hugetlbfs file, and steal huge pages without appropriative permissions. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/proc/array.c')
0 files changed, 0 insertions, 0 deletions