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

I can confirm that this manifested with the 2.6.26-21lenny3 security
upgrade in Feburary (DSA-1996). It seems like what happens is when the
system boots, it runs the /etc/init.d/util-vserver script, which
attempts to automatically start all the guests which have the 'default'
mark. Sometimes things are fine, sometimes some guests give the 'vlogin:
openpty()' error when you try to 'vserver <guest> enter' them. You also
will get an error trying to ssh to the guest, or anything else related
to pty.

Its not reliable which guests get this problem, sometimes its none of
them, sometimes its all of them. When you restart the machine, the only
thing you can do is attempt to enter each guest, and those which give
the openpty() problem, you need to issue a 'vserver <guest> stop;
vserver <guest> start' to get them back. This resolves it every time.

I looked to see if the guest has /dev/pts and /dev/ptmx when first
trying to enter it by doing:

vnamespace -e <guest> ls -l /vservers/<guest>/dev/{ptmx,pts}

this shows me that on an affected guests /dev/pts is empty, but has a
'0' on those that do not have a problem. The /dev/ptmx exists like
normal:

crw-rw-rw- 1 root root 5, 2 2006-11-10 16:07 /vservers/test/dev/ptmx

So the guests that have this problem have no /dev/pts/0, they have a
/dev/pts, just nothing in it. Typically /dev/pts/0 doesn't get created
until you do 'vserver <guest> enter' or use ssh to enter, or something
else allocates a tty. It seems like a 'vserver <guest> enter' doesn't
seem to be able to create it.

Looking at the /proc/mounts in the guest's namespace, with the
folliowing:

vnamespace -e <guest> cat /proc/mounts

I see this:

total 0
rootfs / rootfs rw 0 0
/dev/md0 / ext3 rw,errors=remount-ro,data=ordered 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
/dev/md1 /usr ext3 rw,errors=continue,data=ordered 0 0
/dev/md2 /var ext3 rw,errors=continue,data=ordered 0 0
/dev/loop3 /vservers ext3 rw,errors=continue,data=ordered 0 0
none /vservers/test/proc proc rw,nodev 0 0
/dev/loop3 /vservers/test ext3 rw,errors=continue,data=ordered 0 0

If I look at the way the initscript does the starting, I see that it is
invoked in the following way:

/usr/lib/util-vserver/vserver-wrapper start >/dev/tty8 </dev/tty8 2>/dev/tty8 &

Looking at /dev/tty8, i see a segfault in
/usr/lib/util-vserver/vserver.functions line 907. This is using the
lenny version of the user-space utilities (0.30.216~r2772-6), and line
907 is the opening curly brace as follows:

function _mountVserverInternal
{


Micah