From: Marcelo Tosatti Two threads sharing the same VMA can race in expand_stack, resulting in incorrect VMA size accounting and possibly a "uncovered-by-VMA" pte leak. Fix is to check if the stack has already been expanded after acquiring a lock which guarantees exclusivity (page_table_lock in v2.4 and vma_anon lock in v2.6). Signed-off-by: Andrew Morton --- 25-akpm/mm/mmap.c | 13 +++++++++++++ 1 files changed, 13 insertions(+) diff -puN mm/mmap.c~fix-expand_stack-smp-race mm/mmap.c --- 25/mm/mmap.c~fix-expand_stack-smp-race 2005-01-10 21:14:17.112973400 -0800 +++ 25-akpm/mm/mmap.c 2005-01-10 21:14:17.116972792 -0800 @@ -1496,6 +1496,13 @@ int expand_stack(struct vm_area_struct * */ address += 4 + PAGE_SIZE - 1; address &= PAGE_MASK; + + /* already expanded while waiting for anon_vma lock? */ + if (vma->vm_end >= address) { + anon_vma_unlock(vma); + return 0; + } + size = address - vma->vm_start; grow = (address - vma->vm_end) >> PAGE_SHIFT; @@ -1539,6 +1546,12 @@ int expand_stack(struct vm_area_struct * return -ENOMEM; anon_vma_lock(vma); + /* already expanded while waiting for anon_vma lock? */ + if (vma->vm_start <= address) { + anon_vma_unlock(vma); + return 0; + } + /* * vma->vm_start/vm_end cannot change under us because the caller * is required to hold the mmap_sem in read mode. We need the _