Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Fri, 2026-09-11 at 15:34 +0100, David Woodhouse wrote:
> On Fri, 2026-09-11 at 13:31 +0100, David Woodhouse wrote:
> > 
> >  - While testing hot-plug of xen-net-device we hit an unrelated,
> >    pre-existing heap corruption ("double free or corruption (!prev)")
> >    on qemu exit after hot-plugging a xen-net-device, present on
> >    current master both with and without the fix. It looks like the
> >    same class of exit-notifier-vs-net_cleanup() teardown ordering
> >    issue as commit 9000666052 ("xen-block: fix segv on unrealize")
> >    was for xen-block. That will be chased separately.
> 
> It has a fix for that too now, FWIW, but I don't have the bandwidth
> right now to reimplement it with meat fingers so I might just file the
> bug instead.

Having now found the bandwidth to at least *look* at its fix, it had
added a 'cleanup_done' guard in qemu_cleanup_net_client() but I didn't
like that very much. I think the better answer is for ->cleanup() to be
idempotent much like a gobject's dispose() would be.

I made it go audit them all and find the ones which aren't. Obviously
slirp was the first, and it can set s->slirp=NULL on cleanup to avoid
freeing it again (I made it add a couple of NULL checks in other
places, but those would have been a use-after-free in the current code
anyway).

Then vde, ll2tpv3 and passt also need similar fixes. I'm looking at a
nice simple table of other things to check on for each backend, but I
can't show that here so I won't.

Attachment: smime.p7s
Description: S/MIME cryptographic signature