qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] dump: fix use-after-free for


From: Markus Armbruster
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] dump: fix use-after-free for s->fd
Date: Fri, 31 Oct 2014 07:51:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Michael Tokarev <address@hidden> writes:

> 30.10.2014 10:10, Markus Armbruster wrote:
> []
>> I'm afraid the commit message is a bit misleading.  Let's examine what
>> exactly happens.
>> 
>> dump_iterate() dumps blocks in a loop.  Eventually, get_next_block()
>> returns "no more".  We then call dump_completed().  But we neglect to
>> break the loop!  Broken in commit 4c7e251a.
>> 
>> Because of that, we dump the last block again.  This attempts to write
>> to s->fd, which fails if we're lucky.  The error makes dump_iterate()
>> return unsuccessfully.  It's the only way it can ever return.
>> 
>> Theoretical: if we're not so lucky, something else has opened something
>> for writing and got the same fd.  dump_iterate() then keeps looping,
>> messing up the something else's output, until a write fails, or the
>> process mercifully terminates.
>> 
>> Is this correct?
>> 
>> If yes, let's use this commit message:
>> 
>>     dump: Fix dump-guest-memory termination and use-after-close
>> 
>>     dump_iterate() dumps blocks in a loop.  Eventually, get_next_block()
>>     returns "no more".  We then call dump_completed().  But we neglect to
>>     break the loop!  Broken in commit 4c7e251a.
>> 
>>     Because of that, we dump the last block again.  This attempts to write
>>     to s->fd, which fails if we're lucky.  The error makes dump_iterate()
>>     return failure.  It's the only way it can ever return.
>> 
>>     Theoretical: if we're not so lucky, something else has opened something
>>     for writing and got the same fd.  dump_iterate() then keeps looping,
>>     messing up the something else's output, until a write fails, or the
>>     process mercifully terminates.
>> 
>>     The obvious fix is to restore the return lost in commit 4c7e251a.  But
>>     the root cause of the bug is needlessly opaque loop control.  Replace it
>>     by a clean do ... while loop.
>> 
>>     This makes the badly chosen return values of get_next_block() more
>>     visible.  Cleaning that up is outside the scope of this bug fix.
>> 
>> You can then add my R-by.
>
> So I'm applying this -- which is your patch and your commit message, and
> I really wonder why this is Reviewed-by and not Signed-off-by, with your
> authorship?  It really should be...

You can add mine in addition to Gonglei's.

Signed-off-by: Markus Armbruster <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]