[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 7 Feb 2014 10:13:15 +0100
From: Źmicier Januszkiewicz <gauri@....by>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Xen Security Advisory 84 - integer overflow in
several XSM/Flask hypercalls
The 4.1 patch also notes:
> The index of boolean variables in FLASK_{GET,SET}BOOL was not always checked against the bounds of the array.
> Reported-by: John McDermott <john.mcdermott@....navy.mil>
I wonder, is this something exploitable we should care about (e.g., a
crash triggered by out-of-bounds reads), or it is only some sort of
preventive measure?
2014/2/7 Jan Beulich <JBeulich@...e.com>:
>>>> On 06.02.14 at 18:23, <cve-assign@...re.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> We can provide the three CVE assignments for XSA-84 (as well as the
>> one CVE assignment for XSA-85 and the one CVE assignment for XSA-86).
>> However, could you please clarify:
>>
>>> http://xenbits.xen.org/xsa/advisory-84.html
>>
>>> UPDATES IN VERSION 2
>>> ====================
>>>
>>> Public release.
>>>
>>> The patch for 4.1 was extended to cover a few further similar issues.
>>
>> Here, was the original scope of "The patch for 4.1" (before it was
>> extended) exclusively:
>>
>> "a different overflow issue on FLASK_{GET,SET}BOOL and expose
>> unreasonably large memory allocation to arbitrary guests"
>>
>> ? Or do you mean that, originally, the "patch for 4.1" addressed
>> another vulnerability, and this "different overflow issue" was one of
>> the version-2 extensions to the scope of XSA-84?
>
> The original patch was dealing with just the unbounded memory
> allocation. The missing bounds checking was what the incremental
> addition dealt with.
>
> Jan
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
