Re: [libvirt] [PATCH] audit: eliminate potential null pointer deref when auditing macvtap devices

2011-03-14 Thread Laine Stump
On 03/14/2011 11:25 AM, Eric Blake wrote: On 03/14/2011 09:18 AM, Laine Stump wrote: The newly added call to qemuAuditNetDevice in qemuPhysIfaceConnect was assuming that res_ifname (the name of the macvtap device) was always valid, but this isn't the case. If openMacvtapTap fails, it always retu

Re: [libvirt] [PATCH] audit: eliminate potential null pointer deref when auditing macvtap devices

2011-03-14 Thread Eric Blake
On 03/14/2011 09:18 AM, Laine Stump wrote: > The newly added call to qemuAuditNetDevice in qemuPhysIfaceConnect was > assuming that res_ifname (the name of the macvtap device) was always > valid, but this isn't the case. If openMacvtapTap fails, it always > returns NULL, which would result in a seg

[libvirt] [PATCH] audit: eliminate potential null pointer deref when auditing macvtap devices

2011-03-14 Thread Laine Stump
The newly added call to qemuAuditNetDevice in qemuPhysIfaceConnect was assuming that res_ifname (the name of the macvtap device) was always valid, but this isn't the case. If openMacvtapTap fails, it always returns NULL, which would result in a segv. Since the audit log only needs a record of devi