Re: [Qemu-devel] [qemu-s390x] [PATCH 2/3] hw/s390x: fix memory leak in s390_init_ipl_dev()

[Thomas Huth <thuth@redhat.com>]

On 29.03.2018 12:31, Cornelia Huck wrote:
> On Thu, 29 Mar 2018 11:39:41 +0200
> Greg Kurz <groug@kaod.org> wrote:
> 
>> On Thu, 29 Mar 2018 11:27:21 +0200
>> Igor Mammedov <imammedo@redhat.com> wrote:
>>
>>> On Thu, 29 Mar 2018 11:10:06 +0200
>>> Greg Kurz <groug@kaod.org> wrote:
>>>   
>>>> The string returned by object_property_get_str() is dynamically allocated.
>>>>
>>>> Fixes: 3c4e9baacf4d9
>>>> Signed-off-by: Greg Kurz <groug@kaod.org>
>>>> ---
>>>>  hw/s390x/s390-virtio-ccw.c |    5 ++++-
>>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>>> index 864145a7c6f3..435f7c99e77c 100644
>>>> --- a/hw/s390x/s390-virtio-ccw.c
>>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>>> @@ -246,6 +246,7 @@ static void s390_init_ipl_dev(const char *kernel_filename,
>>>>  {
>>>>      Object *new = object_new(TYPE_S390_IPL);
>>>>      DeviceState *dev = DEVICE(new);
>>>> +    char *netboot_fw_prop;
>>>>  
>>>>      if (kernel_filename) {
>>>>          qdev_prop_set_string(dev, "kernel", kernel_filename);
>>>> @@ -256,9 +257,11 @@ static void s390_init_ipl_dev(const char *kernel_filename,
>>>>      qdev_prop_set_string(dev, "cmdline", kernel_cmdline);
>>>>      qdev_prop_set_string(dev, "firmware", firmware);
>>>>      qdev_prop_set_bit(dev, "enforce_bios", enforce_bios);
>>>> -    if (!strlen(object_property_get_str(new, "netboot_fw", &error_abort))) {
>>>> +    netboot_fw_prop = object_property_get_str(new, "netboot_fw", &error_abort);
>>>> +    if (!strlen(netboot_fw_prop)) {    
>>> probably not really issue here but,
>>> is strlen really safe in case netboot_fw_prop == NULL?
>>>   
>>
>> You're right, object_property_get_str() can theoretically return NULL and
>> strlen() would crash... Not sure how this would happen though. Anyway, the
>> current code doesn't check if object_property_get_str() returns NULL so
>> if this needs to be fixed as well, let's do it in a followup patch.
> 
> I don't think so - if the attribute exists, we'll always get != NULL if
> I read the code correctly.

Right, the property is always there, so this should never be NULL.

 Thomas