[libvirt] [PATCH v2 5/6] qemu: Resolve Coverity FORWARD_NULL
John Ferlan
jferlan at redhat.com
Wed Oct 7 14:12:05 UTC 2015
On 10/07/2015 02:32 AM, Peter Krempa wrote:
> On Fri, Sep 25, 2015 at 12:31:44 -0400, John Ferlan wrote:
>> Coverity notices that net->ifname is potentially referenced after a
>> VIR_FREE(). Looking through history, the vport check code was added by
>> commit id 'df8100463' and later augmented by commit id 'd490f47b'. The
>> data is allocated via virNetDevMacVLanCreateWithVPortProfile, so it is
>> reasonable that it's free'd after the virNetDevMacVLanDeleteWithVPortProfile
>> call. Additionally, the virNetDevTapDelete call was added by commit id
>> '075650ff4', but it doesn't seem there's a corresponding VIR_FREE of
>> the ifname, so include that as well while we're at it.
>>
>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>> ---
>> src/qemu/qemu_process.c | 14 ++++++++++++--
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
>> index f2586a1..e3d1c62 100644
>> --- a/src/qemu/qemu_process.c
>> +++ b/src/qemu/qemu_process.c
>> @@ -5321,6 +5321,7 @@ void qemuProcessStop(virQEMUDriverPtr driver,
>
> Since we are in qemuProcessStop, which means that the whole active
> definition will be nuked a few lines below this code ...
>
Just removing the VIR_FREE(net->ifname) works - that's fine as well. Do
you want to see the diff before pushing?
John
>>
>> def = vm->def;
>> for (i = 0; i < def->nnets; i++) {
>> + bool free_net_iface = false;
>> virDomainNetDefPtr net = def->nets[i];
>> vport = virDomainNetGetActualVirtPortProfile(net);
>>
>> @@ -5332,13 +5333,16 @@ void qemuProcessStop(virQEMUDriverPtr driver,
>> virDomainNetGetActualDirectMode(net),
>> virDomainNetGetActualVirtPortProfile(net),
>> cfg->stateDir));
>> - VIR_FREE(net->ifname);
>> + free_net_iface = true;
>
> .. should we even bother to do this? Just remove the free and let
> virDomainDefFree remove it afterwards either when vm->def is being
> replaced by vm->newDef or when the transient vm object is being nuked
> too.
>
> Peter
>
More information about the libvir-list
mailing list