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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 18/02/14 16:39, Ian Campbell wrote:
> 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.
>
>

If 4.4 gets delayed, and patches such as the RTC series are re-up for
consideration, then this should also be considered.

If not, then 4.5 is fine, along with a backport to 4.4.x and 4.3.x.

~Andrew

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