I had a look at this bug and I seem to have prevented it, i.e.:

njones@fantail:~$ cat /tmp/455832.xml 
<disk type='block'>
  <driver name='virtio'/>
  <source dev='/dev/sdd'/>
  <target dev='vdc' bus='virtio'/>
</disk>

(sdd is a USB stick)

Before patch:

njones@fantail:~$ virsh list; virsh destroy lucid-test; virsh start lucid-test; virsh attach-device lucid-test /tmp/455832.xml; virsh attach-device lucid-test /tmp/455832.xml
 Id Name                 State
----------------------------------
  9 lucid-test           running

Domain lucid-test destroyed

Domain lucid-test started

Device attached successfully

error: Failed to attach device from /tmp/455832.xml
error: server closed connection

After patch:

njones@fantail:~$ virsh list; virsh destroy lucid-test; virsh start lucid-test; virsh attach-device lucid-test /tmp/455832.xml; virsh attach-device lucid-test /tmp/455832.xml
 Id Name                 State
----------------------------------
 10 lucid-test           running

Domain lucid-test destroyed

Domain lucid-test started

Device attached successfully

error: Failed to attach device from /tmp/455832.xml
error: operation failed: target vdc already exists

From GDB w/o patch:
Core was generated by `libvirtd -v'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f3cbe516402 in virCgroupPathOfController (group=0x0, controller=4, key=0x7f3cbe5d6d7c "devices.deny", path=0x7f3cb7fc88d8) at util/cgroup.c:246
246	    if (group->controllers[controller].mountPoint == NULL)
(gdb) p
The history is empty.
(gdb) bt
#0  0x00007f3cbe516402 in virCgroupPathOfController (group=0x0, controller=4, key=0x7f3cbe5d6d7c "devices.deny", path=0x7f3cb7fc88d8) at util/cgroup.c:246
#1  0x00007f3cbe51661c in virCgroupSetValueStr (group=0x0, controller=4, key=0x7f3cbe5d6d7c "devices.deny", value=0x7f3cb0049b40 "b 8:16 rwm") at util/cgroup.c:271
#2  0x00007f3cbe516914 in virCgroupDenyDevice (group=0x0, type=<value optimized out>, major=<value optimized out>, minor=<value optimized out>) at util/cgroup.c:882
#3  0x00007f3cbe516bf4 in virCgroupDenyDevicePath (group=0x0, path=<value optimized out>) at util/cgroup.c:932
#4  0x000000000043ce2b in qemudDomainAttachDevice (dom=0x7f3cb0028920, xml=0x7f3cb006a9d8 "\340\244u") at qemu/qemu_driver.c:5505
#5  0x00007f3cbe551e81 in virDomainAttachDevice (domain=0x7f3cb0028920, 
    xml=0x7f3cb000f080 "<disk type='block'>\n  <driver name='virtio'/>\n  <source dev='/dev/sdb'/>\n  <target dev='vdc' bus='virtio'/>\n</disk>\n") at libvirt.c:5093
#6  0x000000000042296f in remoteDispatchDomainAttachDevice (server=<value optimized out>, client=<value optimized out>, conn=0x758bc0, hdr=<value optimized out>, rerr=0x7f3cb7fc8b80, args=0x7f3cb7fc8c10, 
    ret=0x7f3cb7fc8c60) at remote.c:883
#7  0x0000000000424421 in remoteDispatchClientCall (server=<value optimized out>, client=0x762110, msg=0x7a30f0) at dispatch.c:506
#8  0x00000000004247d3 in remoteDispatchClientRequest (server=0x74f110, client=0x762110, msg=0x7a30f0) at dispatch.c:388
#9  0x000000000041768c in qemudWorker (data=<value optimized out>) at libvirtd.c:1522
#10 0x00007f3cbca0b9ca in start_thread (arg=<value optimized out>) at pthread_create.c:300
#11 0x00007f3cbc76969d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#12 0x0000000000000000 in ?? ()

Basically, it appears that qemudDomainAttachDevice calls virCgroupDenyDevicePath using a NULL pointer, the attached patch will not call cgroup if the pointer is NULL.

I'm not sure if this requires any more tidying up.