On 09/09/2010 08:02 AM, Kevin Wolf wrote:
Or instead of completely removing it, we could add
a size limit, though I suspect that would mean violating some specs.
One thing I was thinking of trying was splitting off the first sector
into a linear buffer, then allocating a new iovec an
Am 09.09.2010 14:52, schrieb Anthony Liguori:
> On 09/09/2010 07:44 AM, Kevin Wolf wrote:
>>> Isn't this an unbounded, guest controlled, malloc? IOW, a guest could
>>> do a request of 4GB and on a 32-bit system crash the qemu instance.
>>>
>> If you're concerned about that, we need to ban qe
On 09/09/2010 07:44 AM, Kevin Wolf wrote:
Isn't this an unbounded, guest controlled, malloc? IOW, a guest could
do a request of 4GB and on a 32-bit system crash the qemu instance.
If you're concerned about that, we need to ban qemu_iovec_to_buffer()
completely. Currently we do the same th
Am 09.09.2010 14:30, schrieb Anthony Liguori:
> On 09/07/2010 07:08 AM, Kevin Wolf wrote:
>> Recenty a patch was committed to protect the first four bytes of an image to
>> avoid "converting" a probed raw image to a different format when a malicious
>> guest writes e.g. a qcow2 header to it.
>>
>>
On 09/07/2010 07:08 AM, Kevin Wolf wrote:
Recenty a patch was committed to protect the first four bytes of an image to
avoid "converting" a probed raw image to a different format when a malicious
guest writes e.g. a qcow2 header to it.
This check relies on the assumption that all qiov entries ar
Recenty a patch was committed to protect the first four bytes of an image to
avoid "converting" a probed raw image to a different format when a malicious
guest writes e.g. a qcow2 header to it.
This check relies on the assumption that all qiov entries are multiples of 512,
which isn't true in prac
