Re: [Xen-devel] [PATCH 4 00/16] XSA55 libelf fixes for unstable

[Matthew Daley <mattjd@xxxxxxxxx>]

On Wed, Jun 5, 2013 at 5:59 AM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> wrote:
> This is version 4 of my (prematurely-released) series to try to fix
> libelf.  This version deals better with some possibly-out-of-control
> loops, fixes the three so-far-known regressions, and should fix the
> 32-bit ARM build.

Looks like there's another issue that needs fixing up in this XSA (surprise!):

setup_hypercall_page (in xc_dom_boot.c) calls xc_dom_p2m_guest with an
unchecked, user-controlled pfn:

Starting program: /usr/local/sbin/xl create /dev/null
kernel=\'check/_usr_lib_debug_vmlinux-3_2_0-4-amd64-37bdfe88206dbe6f75d9c6e021fd9b83c27814d2-5873-0_001
_1e-06-file.2.0-4-amd64\'\;\ name=\'blah\'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Parsing config from /dev/null

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6d8cb01 in xc_dom_p2m_guest (pfn=<optimized out>, dom=0x626fd0)
    at xc_dom.h:338
338         return dom->p2m_host[pfn - dom->rambase_pfn];
(gdb) p pfn
$1 = <optimized out>
(gdb) p dom->rambase_pfn
$2 = 0
(gdb) bt 5
#0  0x00007ffff6d8cb01 in xc_dom_p2m_guest (pfn=<optimized out>, dom=0x626fd0)
    at xc_dom.h:338
#1  setup_hypercall_page (dom=0x626fd0) at xc_dom_boot.c:56
#2  xc_dom_boot_image (dom=dom@entry=0x626fd0) at xc_dom_boot.c:260
#3  0x00007ffff799b85a in libxl__build_pv (gc=gc@entry=0x629390,
    domid=domid@entry=9368, info=info@entry=0x7fffffffdd00,
    state=state@entry=0x625a80) at libxl_dom.c:399
#4  0x00007ffff7991887 in libxl__domain_build (gc=0x629390,
    d_config=d_config@entry=0x7fffffffdcc0, domid=9368,
    state=state@entry=0x625a80) at libxl_create.c:349
(More stack frames follow...)
(gdb) fr 1
#1  setup_hypercall_page (dom=0x626fd0) at xc_dom_boot.c:56
56          domctl.u.hypercall_init.gmfn = xc_dom_p2m_guest(dom, pfn);
(gdb) p pfn
$3 = <optimized out>
(gdb) l
51
52          DOMPRINTF("%s: vaddr=0x%" PRIx64 " pfn=0x%" PRIpfn "", __FUNCTION__,
53                        dom->parms.virt_hypercall, pfn);
54          domctl.cmd = XEN_DOMCTL_hypercall_init;
55          domctl.domain = dom->guest_domid;
56          domctl.u.hypercall_init.gmfn = xc_dom_p2m_guest(dom, pfn);
57          rc = do_domctl(dom->xch, &domctl);
58          if ( rc != 0 )
59              xc_dom_panic(dom->xch,
60                           XC_INTERNAL_ERROR, "%s: HYPERCALL_INIT
failed (rc=%d)",
(gdb) l -
41      static int setup_hypercall_page(struct xc_dom_image *dom)
42      {
43          DECLARE_DOMCTL;
44          xen_pfn_t pfn;
45          int rc;
46
47          if ( dom->parms.virt_hypercall == -1 )
48              return 0;
49          pfn = (dom->parms.virt_hypercall - dom->parms.virt_base)
50              >> XC_DOM_PAGE_SHIFT(dom);
(gdb) p dom->parms.virt_hypercall
$4 = 0
(gdb) p dom->parms.virt_base
$5 = 18446744071562067968
(gdb) p/x dom->parms.virt_base
$6 = 0xffffffff80000000

Here, the silly dom->parms.virt_base is leading to an out-of-bounds
array access to the guest p2m table. (Also, perhaps
dom->parms.virt_hypercall should be being compared to UNSET_ADDR, not
-1, on line 47.)

- Matthew

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