[Qemu-devel] [PATCH v1] vl: Fix possible freed memory accessing

[Qemu-devel] [PATCH v1] vl: Fix possible freed memory accessing

[zhanghailiang]

The logic of pcmcia_socket_unregister is wrong,
which will cause a freed memory accessing

Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
---
Hi,

The function pcmcia_socket_unregister seemes to be unused,
Should it be removed? Thanks.
---
 vl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/vl.c b/vl.c
index dc792fe..bf659b7 100644
--- a/vl.c
+++ b/vl.c
@@ -1545,11 +1545,13 @@ void pcmcia_socket_unregister(PCMCIASocket *socket)
     struct pcmcia_socket_entry_s *entry, **ptr;
 
     ptr = &pcmcia_sockets;
-    for (entry = *ptr; entry; ptr = &entry->next, entry = *ptr)
+    for (entry = *ptr; entry; ptr = &entry->next, entry = *ptr) {
         if (entry->socket == socket) {
             *ptr = entry->next;
             g_free(entry);
+            break;
         }
+    }
 }
 
 void pcmcia_info(Monitor *mon, const QDict *qdict)
-- 
1.7.12.4

Re: [Qemu-devel] [PATCH v1] vl: Fix possible freed memory accessing

[Markus Armbruster]

zhanghailiang <zhang.zhanghailiang@huawei.com> writes:

> The logic of pcmcia_socket_unregister is wrong,
> which will cause a freed memory accessing
>
> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
> ---
> Hi,
>
> The function pcmcia_socket_unregister seemes to be unused,
> Should it be removed? Thanks.

I think we should remove the whole thing: pcmcia_sockets,
pcmcia_socket_register(), pcmcia_socket_unregister, pcmcia_info().
Here's why.

It serves just one purpose: "info pcmcia".  HMP-only, therefore not a
stable interface.  But is it a useful one?

The only caller of pcmcia_socket_register() is pxa2xx_pcmcia_realize(),
of device model "pxa2xx-pcmcia".  As far as I can tell, used only by a
couple of ARM boards: "verdex", "mainstone", "akita", "spitz", "borzoi",
"terrier", "z2", "connex", "tosa".

Of these, only "akita", "spitz", "borzoi", "terrier" and "tosa" insert a
card into the slot, and they do so right on board initialization.
Nothing ever ejects a card from a slot.  Therefore, "info pcmcia"
effectively prints a fixed, machine-specific string so far.  Doesn't
sound useful to me.

If we acquire PCMCIA devices where querying status is interesting, we'll
want a QMP command, so this code will be pretty much useless.

Peter M., what do you think?

Re: [Qemu-devel] [PATCH v1] vl: Fix possible freed memory accessing

[Paolo Bonzini]

Il 19/09/2014 05:37, zhanghailiang ha scritto:
> The logic of pcmcia_socket_unregister is wrong,
> which will cause a freed memory accessing
> 
> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
> ---
> Hi,
> 
> The function pcmcia_socket_unregister seemes to be unused,
> Should it be removed? Thanks.

Perhaps---however, the patch silences a Coverity warning, so it is
worthwhile.  Thanks for doing this!

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

Re: [Qemu-devel] [PATCH v1] vl: Fix possible freed memory accessing

[Peter Maydell]

On 18 September 2014 23:54, Markus Armbruster <armbru@redhat.com> wrote:
> I think we should remove the whole thing: pcmcia_sockets,
> pcmcia_socket_register(), pcmcia_socket_unregister, pcmcia_info().
> Here's why.
>
> It serves just one purpose: "info pcmcia".  HMP-only, therefore not a
> stable interface.  But is it a useful one?
>
> The only caller of pcmcia_socket_register() is pxa2xx_pcmcia_realize(),
> of device model "pxa2xx-pcmcia".  As far as I can tell, used only by a
> couple of ARM boards: "verdex", "mainstone", "akita", "spitz", "borzoi",
> "terrier", "z2", "connex", "tosa".
>
> Of these, only "akita", "spitz", "borzoi", "terrier" and "tosa" insert a
> card into the slot, and they do so right on board initialization.
> Nothing ever ejects a card from a slot.  Therefore, "info pcmcia"
> effectively prints a fixed, machine-specific string so far.  Doesn't
> sound useful to me.
>
> If we acquire PCMCIA devices where querying status is interesting, we'll
> want a QMP command, so this code will be pretty much useless.

I wouldn't particularly object to the info code disappearing. pxa2xx
is pretty old and crufty code at this point and I don't suppose
the pcmcia code has been modernised very much.

(Couldn't you implement a hypothetical pcmcia HMP/QMP command by
scanning the QOM tree for pcmcia device objects now anyway?)

-- PMM

Re: [Qemu-devel] [Qemu-trivial] [PATCH v1] vl: Fix possible freed memory accessing

[Michael Tokarev]

Applied to -trivial, thank you!

/mjt

Re: [Qemu-devel] [Qemu-trivial] [PATCH v1] vl: Fix possible freed memory accessing

[Markus Armbruster]

Michael Tokarev <mjt@tls.msk.ru> writes:

> Applied to -trivial, thank you!

Makes my 'hmp: Remove "info pcmcia"' conflict.  Either revert this one
before applying mine, or resolve the conflict and drop the paragraph
about the bug from my commit message.

Re: [Qemu-devel] [Qemu-trivial] [PATCH v1] vl: Fix possible freed memory accessing

[Michael Tokarev]

22.09.2014 10:23, Markus Armbruster wrote:
> Michael Tokarev <mjt@tls.msk.ru> writes:
> 
>> Applied to -trivial, thank you!
> 
> Makes my 'hmp: Remove "info pcmcia"' conflict.  Either revert this one
> before applying mine, or resolve the conflict and drop the paragraph
> about the bug from my commit message.

Okay, I'll keep an eye on this -- I'm reverting the trivial patch
for now.

/mjt

Re: [Qemu-devel] [Qemu-trivial] [PATCH v1] vl: Fix possible freed memory accessing

[Michael Tokarev]

On 09/22/2014 11:34 AM, Michael Tokarev wrote:
> 22.09.2014 10:23, Markus Armbruster wrote:
>> Michael Tokarev <mjt@tls.msk.ru> writes:
>>
>>> Applied to -trivial, thank you!
>>
>> Makes my 'hmp: Remove "info pcmcia"' conflict.  Either revert this one
>> before applying mine, or resolve the conflict and drop the paragraph
>> about the bug from my commit message.
> 
> Okay, I'll keep an eye on this -- I'm reverting the trivial patch
> for now.

So it looks like the original patch by zhanghailiang still applies,
and your patch, `info pcmcia' removal, hasn't been applied for over
a month. Should I apply the bugfix by zhanghailiang finally?

Thanks,

/mjt

Re: [Qemu-devel] [Qemu-trivial] [PATCH v1] vl: Fix possible freed memory accessing

[Markus Armbruster]

Michael Tokarev <mjt@tls.msk.ru> writes:

> On 09/22/2014 11:34 AM, Michael Tokarev wrote:
>> 22.09.2014 10:23, Markus Armbruster wrote:
>>> Michael Tokarev <mjt@tls.msk.ru> writes:
>>>
>>>> Applied to -trivial, thank you!
>>>
>>> Makes my 'hmp: Remove "info pcmcia"' conflict.  Either revert this one
>>> before applying mine, or resolve the conflict and drop the paragraph
>>> about the bug from my commit message.
>> 
>> Okay, I'll keep an eye on this -- I'm reverting the trivial patch
>> for now.
>
> So it looks like the original patch by zhanghailiang still applies,
> and your patch, `info pcmcia' removal, hasn't been applied for over
> a month. Should I apply the bugfix by zhanghailiang finally?

Please give me a few more days to try getting it committed.

Re: [Qemu-devel] [Qemu-trivial] [PATCH v1] vl: Fix possible freed memory accessing

[Peter Maydell]

On 23 October 2014 07:33, Michael Tokarev <mjt@tls.msk.ru> wrote:
> On 09/22/2014 11:34 AM, Michael Tokarev wrote:
>> 22.09.2014 10:23, Markus Armbruster wrote:
>>> Michael Tokarev <mjt@tls.msk.ru> writes:
>>>
>>>> Applied to -trivial, thank you!
>>>
>>> Makes my 'hmp: Remove "info pcmcia"' conflict.  Either revert this one
>>> before applying mine, or resolve the conflict and drop the paragraph
>>> about the bug from my commit message.
>>
>> Okay, I'll keep an eye on this -- I'm reverting the trivial patch
>> for now.
>
> So it looks like the original patch by zhanghailiang still applies,
> and your patch, `info pcmcia' removal, hasn't been applied for over
> a month. Should I apply the bugfix by zhanghailiang finally?

The 'remove info pcmcia' patch is in target-arm.next:
https://git.linaro.org/people/peter.maydell/qemu-arm.git/shortlog/refs/heads/target-arm.next

it's just that pressure of other stuff plus KVM Forum means
I haven't yet had a chance to scan for other ARM things to
pick up and flush the queue yet. I'll try to do that this
week.

thanks
-- PMM