CVE-2014-1891 CVE-2014-1892 CVE-2014-1893 CVE-2014-1894



integer overflow in several XSM/Flask hypercalls

The FLASK_{GET,SET}BOOL, FLASK_USER and FLASK_CONTEXT_TO_SID suboperations of the flask hypercall are vulnerable to an integer overflow on the input size. The hypercalls attempt to allocate a buffer which is 1 larger than this size and is therefore vulnerable to integer overflow and an attempt to allocate then access a zero byte buffer. (CVE-2014-1891)

Xen 3.3 through 4.1, while not affected by the above overflow, have a different overflow issue on FLASK_{GET,SET}BOOL (CVE-2014-1893) and expose unreasonably large memory allocation to aribitrary guests (CVE-2014-1892).

Xen 3.2 (and presumably earlier) exhibit both problems with the overflow issue being present for more than just the suboperations listed above. (CVE-2014-1894 for the subops not covered above.)

The FLASK_GETBOOL op is available to all domains.

The FLASK_SETBOOL op is only available to domains which are granted access via the Flask policy. However the permissions check is performed only after running the vulnerable code and the vulnerability via this subop is exposed to all domains.

The FLASK_USER and FLASK_CONTEXT_TO_SID ops are only available to domains which are granted access via the Flask policy.

integer overflow



flask: fix reading strings from guest memory

Since the string size is being specified by the guest, we must range check it properly before doing allocations based on it. While for the two cases that are exposed only to trusted guests (via policy restriction) this just uses an arbitrary upper limit (PAGE_SIZE), for the FLASK_[GS]ETBOOL case (which any guest can use) the upper limit gets enforced based on the longest name across all boolean settings.

range check the string size.


Attempting to access the result of a zero byte allocation results in a processor fault leading to a denial of service.