mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Jan Beulich
02cbeeb620
The way the lock is currently being used in get_maptrack_handle(), it protects only the maptrack limit: The function acts on current's list only, so races on list accesses are impossible even without the lock. Otoh list access races are possible between __get_maptrack_handle() and put_maptrack_handle(), due to the invocation of the former for other than current from steal_maptrack_handle(). Introduce a per-vCPU lock for list accesses to become race free again. This lock will be uncontended except when it becomes necessary to take the steal path, i.e. in the common case there should be no meaningful performance impact. When in get_maptrack_handle adds a stolen entry to a fresh, empty, freelist, we think that there is probably no concurrency. However, this is not a fast path and adding the locking there makes the code clearly correct. Also, while we are here: the stolen maptrack_entry's tail pointer was not properly set. Set it. This is CVE-2017-12136 / XSA-228. Reported-by: Ian Jackson <ian.jackson@eu.citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
xen-bugtool =========== The xen-bugtool command line application will collate the Xen dmesg output, details of the hardware configuration of your machine, information about the build of Xen that you are using, plus, if you allow it, various logs. The information collated can either be posted to a Xen Bugzilla bug (this bug must already exist in the system, and you must be a registered user there), or it can be saved as a .tar.bz2 for sending or archiving. The collated logs may contain private information, and if you are at all worried about that, you should not use this tool, or you should explicitly exclude those logs from the archive. xen-bugtool is wholly interactive, so simply run it, and answer the questions.