virtqemud will also coredump when try to start a vm with vds interface type.
It is a negative scenario for kvm VMs, the vm should not start successfully with reasonable error msg, but virtqemud should not crash.

# pidof virtqemud
11828

# virsh dumpxml test
<domain type='kvm'>
  <name>test</name>
...
 <devices>
...
<interface type='vds'>
      <mac address='52:54:00:22:c9:42'/>
      <source switchid='12345678-1234-1234-1234-123456789abc' portid='6' portgroupid='pg-4321' connectionid='12345'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x10' slot='0x01' function='0x0'/>
    </interface>
 </devices>
</domain>

# virsh start test 
error: Disconnected from qemu:///system due to end of file
error: Failed to start domain 'test'
error: End of file while reading data: Input/output error

# pidof virtqemud
11918

#0  0x00007f38c54f75fc in virJSONValueObjectInsert (object=object@entry=0x0, 
    key=key@entry=0x7f38c079089d "id", value=value@entry=0x7f38c1ffaf80, 
    prepend=prepend@entry=false) at ../src/util/virjson.c:552
        pair = {key = 0x9 <error: Cannot access memory at address 0x9>, 
          value = 0x18}
        ret = <optimized out>
        __FUNCTION__ = "virJSONValueObjectInsert"
#1  0x00007f38c54f7de5 in virJSONValueObjectInsertString (object=0x0, 
    key=0x7f38c079089d "id", value=<optimized out>, prepend=<optimized out>)
    at ../src/util/virjson.c:599
        jvalue = 0x7f38a402d810
#2  0x00007f38c54f7ef4 in virJSONValueObjectAppendStringPrintf (object=0x0, 
    key=key@entry=0x7f38c079089d "id", fmt=fmt@entry=0x7f38c077cdca "host%s")
    at ../src/util/virjson.c:625
        ap = {{gp_offset = 32, fp_offset = 48, 
            overflow_arg_area = 0x7f38c1ffb0a0, 
            reg_save_area = 0x7f38c1ffafd0}}
        str = 0x7f38a402c700 "hostnet0"
#3  0x00007f38c06987d8 in qemuBuildHostNetProps (vm=<optimized out>, 
    net=0x7f38ac049650) at ../src/qemu/qemu_command.c:3996
        netType = <optimized out>
        i = <optimized out>
        netpriv = <optimized out>
        netprops = 0x0
        __FUNCTION__ = "qemuBuildHostNetProps"


We apparently try to call virJSONValueObjectAppendStringPrintf on a object which is NULL.

This was caused by commit:

commit b6738ffc9f8be5a2a61236cd9bef7fd317982f01
Author: Peter Krempa <pkrempa>
Date:   Thu May 14 22:50:59 2020 +0200

    qemu: command: Generate -netdev command line via JSON->cmdline conversion
    
    The 'netdev_add' command was recently formally described in qemu via the
    QMP schema. This means that it also requires the arguments to be
    properly formatted. Our current approach is to generate the command line
    and then use qemuMonitorJSONKeywordStringToJSON to get the JSON
    properties for the monitor. This will not work if we need to pass some
    fields as numbers or booleans.
    
    In this step we re-do internals of qemuBuildHostNetStr to format a JSON
    object which is converted back via virQEMUBuildNetdevCommandlineFromJSON
    to the equivalent command line. This will later allow fixing of the
    monitor code to use the JSON object directly rather than rely on the
    conversion.

$ git desc b6738ffc9f8
v6.3.0-139-gb6738ffc9f

Ah, so the commit I've mentioned above introduced code that made it easy to do a mistake when adding a new interface type, which is what actually caused to code to crash. Previously the code adding the alias could not be reached without the object being allocated.

Fixed upstream:

commit f3a73384092f798261d99bf1ce099c8ea6cc91a9
Author: Peter Krempa <pkrempa>
Date:   Mon Mar 6 09:18:51 2023 +0100

    qemuBuildHostNetProps: Report proper errors for unhandled interface types
    
    VIR_DOMAIN_NET_TYPE_NULL and VIR_DOMAIN_NET_TYPE_VDS are not implemented
    for the qemu driver but the formatter code in 'qemuBuildHostNetProps'
    didn't report an error for them and didn't even return from the function
    when they were encountered.
    
    This caused a crash in 'virJSONValueObjectAppendStringPrintf' which
    does not tolerate NULL JSON object to append to when the unsupported
    devices were used.
    
    Properly report error when unhandled devices are encountered. This also
    includes the case for VIR_DOMAIN_NET_TYPE_HOSTDEV, but that code path
    should never be reached.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2175582
    Fixes: bac6b266fb6a / 6457619d186
    Fixes: 0225483adce
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Ján Tomko <jtomko>

v9.1.0-84-gf3a7338409

No such issue exists in automation function test job with libvirt-9.2.0-1.el9.x86_64.

Sorry, Please ignore comment 6.
Test with libvirt-9.2.0-1.el9.x86_64, the result is as expected, virtqemud will not coredump, and the error msg makes sense.

1. Try to start vm with interface type as "null":
# virsh dumpxml avocado-vt-vm1 --xpath //interface 
<interface type="null">
  <mac address="52:54:00:22:c9:42"/>
  <model type="virtio"/>
  <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>

# virsh start avocado-vt-vm1 
error: Failed to start domain 'avocado-vt-vm1'
error: unsupported configuration: network device type 'null' is not supported by this hypervisor

2. Try to start vm with interface type as "vds":
# virsh dumpxml avocado-vt-vm1 --xpath //interface 
<interface type="vds">
  <mac address="52:54:00:22:c9:42"/>
  <source switchid="12345678-1234-1234-1234-123456789abc" portid="6" portgroupid="pg-4321" connectionid="12345"/>
  <model type="rtl8139"/>
  <address type="pci" domain="0x0000" bus="0x10" slot="0x01" function="0x0"/>
</interface>

# virsh start avocado-vt-vm1 
error: Failed to start domain 'avocado-vt-vm1'
error: unsupported configuration: network device type 'vds' is not supported by this hypervisor

Test on libvirt-9.3.0-2.el9.x86_64 with the scenarios in comment 7, the result is the same, all expected.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: libvirt security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:6409