+-- On Wed, 15 Nov 2017, Dr. David Alan Gilbert wrote --+
| * Paolo Bonzini (pbonz...@redhat.com) wrote:
| > However, PJP's patch breaks migration by changing a 4-byte field to
| > 1-byte. The correct fix is to range-check the fields in
| > ps2_common_post_load.
|
| Agreed.
Sent revised patch
On 15/11/2017 14:30, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>> On 15/11/2017 13:51, Daniel P. Berrange wrote:
>>> If you're concerned that someone is tampering with QEMU state
>>> in transit during migration, then you're going to end up playing
>>>
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 15/11/2017 13:51, Daniel P. Berrange wrote:
> > If you're concerned that someone is tampering with QEMU state
> > in transit during migration, then you're going to end up playing
> > whack-a-mole across the entire QEMU codebase IMHO. The answer
> >
On 15/11/2017 13:51, Daniel P. Berrange wrote:
> If you're concerned that someone is tampering with QEMU state
> in transit during migration, then you're going to end up playing
> whack-a-mole across the entire QEMU codebase IMHO. The answer
> to the problem of tampering is to have encryption of
On Wed, Nov 15, 2017 at 06:16:02PM +0530, P J P wrote:
> From: Prasad J Pandit
>
> During Qemu guest migration, a destination process invokes ps2
> post_load function. In that, if 'rptr' and 'count' fields were
> tampered, it could lead to OOB access or infinite loop
From: Prasad J Pandit
During Qemu guest migration, a destination process invokes ps2
post_load function. In that, if 'rptr' and 'count' fields were
tampered, it could lead to OOB access or infinite loop issues.
Change their type to 'uint8_t' so they remain within bounds.