From: Gonglei <arei.gonglei@huawei.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "qemu-trivial@nongnu.org" <qemu-trivial@nongnu.org>,
"lcapitulino@redhat.com" <lcapitulino@redhat.com>,
Michael Tokarev <mjt@tls.msk.ru>,
"Huangpeng \(Peter\)" <peter.huangpeng@huawei.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH v2] dump: fix use-after-free for s->fd
Date: Thu, 30 Oct 2014 18:50:18 +0800 [thread overview]
Message-ID: <545217EA.3070200@huawei.com> (raw)
In-Reply-To: <87wq7h3o7r.fsf@blackfin.pond.sub.org>
On 2014/10/30 17:23, Markus Armbruster wrote:
> Michael Tokarev <mjt@tls.msk.ru> writes:
>
>> 30.10.2014 10:10, Markus Armbruster wrote:
>>> <arei.gonglei@huawei.com> writes:
>>>
>>>> From: Gonglei <arei.gonglei@huawei.com>
>>>>
>>>> After commit 4c7e251a (), when dump memory completed,
>>>> the s->fd will be closed twice. We should return
>>>> directly when dump completed.
>>>>
>>>> Using do/while block, make the badly chosen return
>>>> values of get_next_block() more visible and fix
>>>> this issue.
>>>>
>>>> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
>>>
>>> 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?
>>
>> Heh. I was starring at all this last 20 minutes, re-reading the
>> original v1 patch and your (Marcus) followup suggestion, trying to
>> match the commit description with the actual happening and with the
>> "no return" case which was before this patch. Oh well.
>>
>> Yes, this looks correct indeed, we come to the same conclusion.
>> But at this stage I really wonder if this is a -trivial material.
>
> Distinguished old math professor does a proof on the blackboard. At
> some point he faces the audience and says "this is trivial". Faces
> blackboard, pauses. "Is it trivial?" Pauses again. Storms out of the
> classroom. After ten minutes, he comes back and exclaims "it *is*
> trivial!"
>
:)
>> (I can apply it to -trivial because no maintainer is listed for
>> this file and because after some digging it becomes obvious).
>
> Appreciated!
Do I need to send v3 for changing commit message, or
/mjt do it directly? Thanks
Best regards,
-Gonglei
WARNING: multiple messages have this Message-ID (diff)
From: Gonglei <arei.gonglei@huawei.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "qemu-trivial@nongnu.org" <qemu-trivial@nongnu.org>,
"lcapitulino@redhat.com" <lcapitulino@redhat.com>,
Michael Tokarev <mjt@tls.msk.ru>,
"Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] dump: fix use-after-free for s->fd
Date: Thu, 30 Oct 2014 18:50:18 +0800 [thread overview]
Message-ID: <545217EA.3070200@huawei.com> (raw)
In-Reply-To: <87wq7h3o7r.fsf@blackfin.pond.sub.org>
On 2014/10/30 17:23, Markus Armbruster wrote:
> Michael Tokarev <mjt@tls.msk.ru> writes:
>
>> 30.10.2014 10:10, Markus Armbruster wrote:
>>> <arei.gonglei@huawei.com> writes:
>>>
>>>> From: Gonglei <arei.gonglei@huawei.com>
>>>>
>>>> After commit 4c7e251a (), when dump memory completed,
>>>> the s->fd will be closed twice. We should return
>>>> directly when dump completed.
>>>>
>>>> Using do/while block, make the badly chosen return
>>>> values of get_next_block() more visible and fix
>>>> this issue.
>>>>
>>>> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
>>>
>>> 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?
>>
>> Heh. I was starring at all this last 20 minutes, re-reading the
>> original v1 patch and your (Marcus) followup suggestion, trying to
>> match the commit description with the actual happening and with the
>> "no return" case which was before this patch. Oh well.
>>
>> Yes, this looks correct indeed, we come to the same conclusion.
>> But at this stage I really wonder if this is a -trivial material.
>
> Distinguished old math professor does a proof on the blackboard. At
> some point he faces the audience and says "this is trivial". Faces
> blackboard, pauses. "Is it trivial?" Pauses again. Storms out of the
> classroom. After ten minutes, he comes back and exclaims "it *is*
> trivial!"
>
:)
>> (I can apply it to -trivial because no maintainer is listed for
>> this file and because after some digging it becomes obvious).
>
> Appreciated!
Do I need to send v3 for changing commit message, or
/mjt do it directly? Thanks
Best regards,
-Gonglei
next prev parent reply other threads:[~2014-10-30 10:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 6:01 [Qemu-trivial] [PATCH v2] dump: fix use-after-free for s->fd arei.gonglei
2014-10-30 6:01 ` [Qemu-devel] " arei.gonglei
2014-10-30 7:10 ` [Qemu-trivial] " Markus Armbruster
2014-10-30 7:10 ` Markus Armbruster
2014-10-30 7:33 ` [Qemu-trivial] " zhanghailiang
2014-10-30 7:33 ` zhanghailiang
2014-10-30 7:42 ` [Qemu-trivial] " Michael Tokarev
2014-10-30 7:42 ` [Qemu-devel] [Qemu-trivial] " Michael Tokarev
2014-10-30 9:23 ` [Qemu-trivial] [Qemu-devel] " Markus Armbruster
2014-10-30 9:23 ` [Qemu-devel] [Qemu-trivial] " Markus Armbruster
2014-10-30 10:50 ` Gonglei [this message]
2014-10-30 10:50 ` Gonglei
2014-10-30 13:54 ` [Qemu-trivial] [Qemu-devel] " Michael Tokarev
2014-10-30 13:54 ` [Qemu-devel] [Qemu-trivial] " Michael Tokarev
2014-10-31 1:43 ` [Qemu-trivial] [Qemu-devel] " Gonglei
2014-10-31 1:43 ` [Qemu-devel] [Qemu-trivial] " Gonglei
2014-10-31 7:18 ` [Qemu-trivial] [Qemu-devel] " Michael Tokarev
2014-10-31 7:18 ` [Qemu-devel] [Qemu-trivial] " Michael Tokarev
2014-10-31 7:40 ` [Qemu-trivial] [Qemu-devel] " Gonglei
2014-10-31 7:40 ` [Qemu-devel] [Qemu-trivial] " Gonglei
2014-10-31 6:51 ` [Qemu-trivial] [Qemu-devel] " Markus Armbruster
2014-10-31 6:51 ` [Qemu-devel] [Qemu-trivial] " Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545217EA.3070200@huawei.com \
--to=arei.gonglei@huawei.com \
--cc=armbru@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=peter.huangpeng@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.