On Tue, 2011-03-15 at 16:48 +0100, Pascal Vitoux wrote: > Package: linux-2.6 > Version: 2.6.32-30 > Severity: important > > When a process starts and ends inside a virtual server, virtual memory > reported > by /proc/virtual/xxx/limit (as VM) decreases (at least by 1). The value drifts > slowly and reaches negative values. > > As long as no hard/soft limit is set, this bug seems to have no incidence. > Otherwise, the virtual server become unusable when virtual memory reaches > negative values (memory allocation failures, new process get killed) > > Someone reports the same issue on linux-vserver mailling list : > http://list.linux-vserver.org/archive?mss:4894:olhpkllgpffjhcfianop > > After some tests and kernel rebuilds, it turns out that : > - previous version (2.6.32-29) is not affected > - drift does not occur when I exclude the patch debian/exec-Get-rid-of- > linux_binprm-vma_pages.patch
The purpose of this patch is to avoid an ABI change, which would be disruptive to users who make use of external modules. > This patch is related to : > bugfix/all/exec-make-argv-envp-memory-visible-to-oom-killer.patch > bugfix/all/exec-copy-and-paste-the-fixes-into-compat_do_execve-paths.patch [...] It looks like these don't do enough on VServer, anyway: the memory used by arguments and environment is no longer hidden from the OOM killer, it *is* hidden from VServer per-server accounting. The attached patch (on top of 2.6.32-31) appears to fix this. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
From: Ben Hutchings <b...@decadent.org.uk> Subject: [PATCH] vserver: Complete fix for CVE-2010-4243 VServer requires all adjustments to mm_struct::total_vm to be accounted to the server as well. Signed-off-by: Ben Hutchings <b...@decadent.org.uk> --- --- a/fs/exec.c +++ b/fs/exec.c @@ -169,7 +169,7 @@ return; down_write(&mm->mmap_sem); - mm->total_vm += diff; + vx_vmpages_add(mm, diff); up_write(&mm->mmap_sem); }
signature.asc
Description: This is a digitally signed message part
