[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] tools/libxl: Don't read off the end of tinfo[]
On 18/02/14 18:14, Andrew Cooper wrote: > 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 Ping? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |