On Thu, Feb 18, 2010 at 05:24:05PM +0000, Dan Gardner wrote:
> Unfortunately it seems my fix does not work. The problem is not
> consistently reproducible, hence my belief I had fixed it.
>
> I tried backporting the util-vserver package from squeeze
> (0.30.216-pre2864-1) and had exactly the same problem.
>
> The problem appears to be caused by failure of old_mmap() in
> secure-mount. Here is the strace output of a failed secure-mount:
>

did you ask the vserver guys on their irc channel for support on aboves?
afair they are quite responsive there.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100218175412.GD12102@baikonur.stro.at">http://lists.debian.org/20100218175412.GD12102@baikonur.stro.at

On Thu, 18 Feb 2010, Dan Gardner wrote:


The problem appears to be caused by failure of old_mmap() in
secure-mount. Here is the strace output of a failed secure-mount:

execve("/usr/lib/util-vserver/secure-mount",
["/usr/lib/util-vserver/secure-mou"..., "-a", "--chroot", "--fstab",
"/etc/vservers/XXX/fstab", "--rootfs", "no"], [/* 31 vars */]) = 0
open(".", O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 3
open("/", O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 4
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
open("/etc/vservers/XXX/fstab", O_RDONLY|O_LARGEFILE) = 5
_llseek(5, 0, [393], SEEK_END) = 0
_llseek(5, 0, [0], SEEK_SET) = 0
read(5, "none /proc proc defaults 0 0
no"..., 394) = 393
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0xbffff28408086038) = 0x40001000
chdir("/") = 0
fchdir(3) = 0
chroot(".") = 0
chdir("/proc") = 0
open(".", O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 6
fchdir(4) = 0
chroot(".") = 0
fchdir(6) = 0
close(6) = 0
mount("none", ".", "proc", MS_NODEV, "") = 0
fchdir(3) = 0
chroot(".") = 0
open("/etc/mtab", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0644) = 6
fcntl(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=0}) = 0
write(6, "none"..., 4) = 4
write(6, " "..., 1) = 1
write(6, "/proc"..., 5) = 5
write(6, " "..., 1) = 1
write(6, "proc"..., 4) = 4
write(6, " "..., 1) = 1
write(6, "defaults"..., 8) = 8
write(6, " 0 0
"..., 5) = 5
close(6) = 0
fchdir(4) = 0
chroot(".") = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0xbffff28408086038) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


The last parameter to mmap should be the offset where the caller wants
data to be initialized (AFAIU). So what's that absurd value
("0xbffff28408086038") there? That's way out in the stratosphere. Well
whatever, I don't want to pretend I understand anything about the mmap
syscall interface.


However, 2.6.26-21lenny1 messed with mmap. From Debian's changelog:

linux-2.6 (2.6.26-21lenny1) stable-security; urgency=high

[ dann frazier ]
...
* Fix several issues with mmap/mremap (CVE-2010-0291)
...

-- dann frazier <dannf@debian.org> Fri, 29 Jan 2010 17:20:16 -0700

CVE-2010-0291 [1] references this discussion [2] which discusses tricky
implications of the patch on virtualisation [3] - which is exactly
the place where we are standing: vserver. So I think I can see stuff
peeling off the space shuttle however don't know how to fix it. Contacting
NASA at vserver-ML additionally to the Debian engineers sounds like a good
idea.

*t

[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0291
[2] http://marc.info/?l=linux-arch&m=126004438008670&w=2
[3] http://marc.info/?l=linux-arch&m=126012243613146&w=2



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: alpine.DEB.2.00.1002182147160.10435@tpo-laptop">http://lists.debian.org/alpine.DEB.2.00.1002182147160.10435@tpo-laptop