Re: [Xen-devel] [PATCH] tools/libxl: Don't read off the end of tinfo[]

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-02-18 at 15:59 +0000, Andrew Cooper wrote:
> It is very common for BIOSes to advertise more cpus than are actually present
> on the system, and mark some of them as offline.  This is what Xen does to
> allow for later CPU hotplug, and what BIOSes common to multiple different
> systems do to to save fully rewriting the MADT in memory.
> 
> An excerpt from `xl info` might look like:
> 
> ...
> nr_cpus                : 2
> max_cpu_id             : 3
> ...
> 
> Which shows 4 CPUs in the MADT, but only 2 online (as this particular box is
> the dual-core rather than the quad-core SKU of its particular brand)
> 
> Because of the way Xen exposes this information, a libxl_cputopology array is
> bounded by 'nr_cpus', while cpu bitmaps are bounded by 'max_cpu_id + 1'.
> 
> The current libxl code has two places which erroneously assume that a
> libxl_cputopology array is as long as the number of bits found in a cpu
> bitmap, and valgrind complains:
> 
> ==14961== Invalid read of size 4
> ==14961==    at 0x407AB7F: libxl__get_numa_candidate (libxl_numa.c:230)
> ==14961==    by 0x407030B: libxl__build_pre (libxl_dom.c:167)
> ==14961==    by 0x406246F: libxl__domain_build (libxl_create.c:371)
> ...
> ==14961==  Address 0x4324788 is 8 bytes after a block of size 24 alloc'd
> ==14961==    at 0x402669D: calloc 
> (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==14961==    by 0x4075BB9: libxl__zalloc (libxl_internal.c:83)
> ==14961==    by 0x4052F87: libxl_get_cpu_topology (libxl.c:4408)
> ==14961==    by 0x407A899: libxl__get_numa_candidate (libxl_numa.c:342)
> ...
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>

Unless someone argues otherwise this is going into my 4.5 pile.



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