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
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
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