From: Peter Krempa <pkrempa@redhat.com>

On failure during the preparation step of migration protocol v3 the
client (potentially running inside the source daemon) can crash as the
remote driver frees internal data of the virStream but doesn't clear out
the pointer. The private data freeing function then tries to unref the
internal data again.

When 'remoteDomainMigratePrepareTunnel3' was introduced in commit
d59e14a1a2 it used the code the RPC generator generated as inspiration,
which didn't clean out the code.

This was later addressed by commit be5ec76630 which added the clearing
to the generator but didn't fix the one instance that was manually
implemented.

Later when 'remoteDomainMigratePrepareTunnel3Params' in cca4d10d82 it
copied the un-fixed manual implementation.

This only became a problem once commit fbcb7386 introduced a freeing
function for the 'privateData' field.

In addition to synchronize the clearing of the 'privateData' of the
stream in the hand-written code, this patch also clears out the 'ff'
function pointer so that the clearing function is not called even on
NULL data.

Closes: https://gitlab.com/libvirt/libvirt/-/work_items/939
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
---
 src/remote/remote_driver.c | 6 ++++++
 src/rpc/gendispatch.pl     | 1 +
 2 files changed, 7 insertions(+)

diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 5c358d58c4..7fb32dce97 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -5868,6 +5868,9 @@ remoteDomainMigratePrepareTunnel3(virConnectPtr dconn,
              (xdrproc_t) xdr_remote_domain_migrate_prepare_tunnel3_ret, (char *) &ret) == -1) {
         virNetClientRemoveStream(priv->client, netst);
         virObjectUnref(netst);
+        st->driver = NULL;
+        st->privateData = NULL;
+        st->ff = NULL;
         return -1;
     }

@@ -6629,6 +6632,9 @@ remoteDomainMigratePrepareTunnel3Params(virConnectPtr dconn,
              (char *) &ret) == -1) {
         virNetClientRemoveStream(priv->client, netst);
         virObjectUnref(netst);
+        st->driver = NULL;
+        st->privateData = NULL;
+        st->ff = NULL;
         goto cleanup;
     }

diff --git a/src/rpc/gendispatch.pl b/src/rpc/gendispatch.pl
index 252562ccfd..a57340d856 100755
--- a/src/rpc/gendispatch.pl
+++ b/src/rpc/gendispatch.pl
@@ -1904,6 +1904,7 @@ elsif ($mode eq "client") {
             print "        virObjectUnref(netst);\n";
             print "        st->driver = NULL;\n";
             print "        st->privateData = NULL;\n";
+            print "        st->ff = NULL;\n";
         }

         print "        goto cleanup;\n";
-- 
2.56.0

On a Tuesday in 2026, Peter Krempa via Devel wrote:
>From: Peter Krempa <pkrempa@redhat.com>
>
>On failure during the preparation step of migration protocol v3 the
>client (potentially running inside the source daemon) can crash as the
>remote driver frees internal data of the virStream but doesn't clear out
>the pointer. The private data freeing function then tries to unref the
>internal data again.
>
>When 'remoteDomainMigratePrepareTunnel3' was introduced in commit
>d59e14a1a2 it used the code the RPC generator generated as inspiration,
>which didn't clean out the code.
>
>This was later addressed by commit be5ec76630 which added the clearing
>to the generator but didn't fix the one instance that was manually
>implemented.
>
>Later when 'remoteDomainMigratePrepareTunnel3Params' in cca4d10d82 it
>copied the un-fixed manual implementation.
>
>This only became a problem once commit fbcb7386 introduced a freeing
>function for the 'privateData' field.
>
>In addition to synchronize the clearing of the 'privateData' of the
>stream in the hand-written code, this patch also clears out the 'ff'
>function pointer so that the clearing function is not called even on
>NULL data.
>
>Closes: https://gitlab.com/libvirt/libvirt/-/work_items/939
>Signed-off-by: Peter Krempa <pkrempa@redhat.com>
>---
> src/remote/remote_driver.c | 6 ++++++
> src/rpc/gendispatch.pl     | 1 +
> 2 files changed, 7 insertions(+)
>

Reviewed-by: Ján Tomko <jtomko@redhat.com>

Jano