[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#570382: after upgrade: "vlogin: openpty(): No such file or directory"]

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\t/proc\t\tproc\tdefaults\t\t0 0\nno"..., 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\n"..., 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
Reply to: