Re: [Xen-devel] [Pkg-xen-devel] Bug#784880: xen-utils-4.4: xl segv when it can't rename log files

[Ian Campbell <ijc@xxxxxxxxxx>]

Control: tag -1 +upstream +forwarded

On Sun, 2015-05-10 at 12:33 +1000, Russell Coker wrote:
> Package: xen-utils-4.4
> Version: 4.4.1-9
> Severity: normal
> 
> # /usr/lib/xen-4.4/bin/xl create -c /etc/xen/katana 
> Parsing config from /etc/xen/katana
> libxl: error: libxl_utils.c:217:logrename: failed to rotate logfile -
> could not rename /var/log/xen/qemu-dm-katana.log.6
> to /var/log/xen/qemu-dm-katana.log.7: Permission denied
> Segmentation fault
> 
> The above happens repeatably when I run xl on a system where renaming log 
> files
> is not permitted.

The caller of logrename, which is libxl_create_logfile, does the right
thing and propagates the error.

There are three callers of libxl_create_logfile in the tree.
libxl__bootloader_run and do_daemonize by inspection look to have
correct error handling, however libxl__create_qemu_logfile looks very
suspicious even in the latest code (hence tagging as upstream).

        static int libxl__create_qemu_logfile(libxl__gc *gc, char *name)
        {
            char *logfile;
            int logfile_w;
        
            libxl_create_logfile(CTX, name, &logfile);
            logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
            free(logfile);
        
            if (logfile_w < 0) {
                LOGE(ERROR, "unable to open Qemu logfile");
                return ERROR_FAIL;
            }
        
            return logfile_w;
        }
        
No error handling on the libxl_create_logfile at all, so it tries to
dereference the NULL logfile in the call to open. This also fits in with
the path name in the log.

Ian.

> 
> [4746481.560999] xl[9245]: segfault at 0 ip           (null) sp 
> 00007ffcebe12858 error 14 in xl[400000+24000]
> [4746626.766885] xl[9313]: segfault at 0 ip           (null) sp 
> 00007ffcd0340d18 error 14 in xl[400000+24000]
> 
> Above are the kernel messages from two runs of xl.
> 
> In this case the files were read-only due to a bug in SE Linux policy, but 
> they
> could be read-only due to a filesystem error, use of chattr +i, or other
> reasons.  It would be OK for xl to report an error and abort, pretty much
> anything other than a SEGV would do.
> 
> -- System Information:
> Debian Release: 8.0
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages xen-utils-4.4 depends on:
> ii  e2fslibs          1.42.12-1.1
> ii  libc6             2.19-18
> ii  libncurses5       5.9+20140913-1+b1
> ii  libtinfo5         5.9+20140913-1+b1
> ii  libxen-4.4        4.4.1-9
> ii  libxenstore3.0    4.4.1-9
> ii  libyajl2          2.1.0-2
> ii  python2.7         2.7.9-2
> pn  python:any        <none>
> ii  xen-utils-common  4.4.1-9
> 
> Versions of packages xen-utils-4.4 recommends:
> ii  bridge-utils                                   1.5-9
> pn  grub-xen-host                                  <none>
> ii  qemu-system-x86                                1:2.1+dfsg-11
> ii  xen-hypervisor-4.4-amd64 [xen-hypervisor-4.4]  4.4.1-9
> 
> xen-utils-4.4 suggests no packages.
> 
> -- no debconf information
> 
> _______________________________________________
> Pkg-xen-devel mailing list
> Pkg-xen-devel@xxxxxxxxxxxxxxxxxxxxxxx
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel