8 files changed, 228 insertions, 0 deletions
diff --git a/results/classifier/108/other/284 b/results/classifier/108/other/284
new file mode 100644
index 000000000..d05478a70
--- /dev/null
+++ b/results/classifier/108/other/284
@@ -0,0 +1,16 @@
+socket: 0.916
+performance: 0.506
+network: 0.451
+graphic: 0.336
+semantic: 0.155
+device: 0.151
+debug: 0.135
+vnc: 0.126
+files: 0.098
+boot: 0.055
+PID: 0.043
+other: 0.018
+permissions: 0.015
+KVM: 0.014
+
+Assertion failed: (buf_len != 0), function soread, file socket.c, line 183.
diff --git a/results/classifier/108/other/2840 b/results/classifier/108/other/2840
new file mode 100644
index 000000000..6fa329c28
--- /dev/null
+++ b/results/classifier/108/other/2840
@@ -0,0 +1,36 @@
+graphic: 0.701
+vnc: 0.678
+device: 0.655
+performance: 0.583
+socket: 0.575
+network: 0.562
+boot: 0.515
+PID: 0.515
+debug: 0.510
+permissions: 0.497
+files: 0.481
+KVM: 0.375
+semantic: 0.341
+other: 0.211
+
+After converting the Windows 10 system disk from qcow2 to LUKS format with pre-allocated space, the system fails to boot
+Description of problem:
+When converting a qcow2 file containing an installed Windows 10 system to LUKS format, using the --target-is-zero parameter in the conversion command prevents the LUKS image from shrinking. However, when attempting to boot the virtual machine with the converted LUKS file, VNC login shows a black screen, and the system fails to start. If the conversion is performed without the --target-is-zero parameter, the system boots up normally
+Steps to reproduce:
+1. create a luks image
+qemu-img create -f qcow2 --object secret,data=123,id=sec0 -o preallocation=full,encrypt.format=luks,encrypt.key-secret=sec0 encry_ok.qcow2 50G
+2.
+qemu-img convert -t none -T none --object secret,id=sec0,data=123 -f qcow2 ./windows10.qcow2  -n -m 1 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=encry_ok.qcow2 --target-is-zero
+
+windows10.qcow2 container windows20 system and  it can be booted
+3.
+./qemu-system-x86_64  -accel kvm -cpu SandyBridge  -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1  -smp 4  -object secret,id=sec0,data=123,format=raw -drive if=none,driver=qcow2,file.filename=/sdc1/luzhipeng/encry_ok.qcow2,encrypt.key-secret=sec0,id=drive0,cache=none  -device virtio-blk,drive=drive0,bootindex=1  -monitor stdio -vnc :4
+
+4. vnc shows a black screen, and the system fails to start
+
+5. if use convert command:
+qemu-img convert -t none -T none --object secret,id=sec0,data=123 -f qcow2 ./windows10.qcow2  -n -m 1 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=encry_ok.qcow2
+
+6. the windows10 system can start successful
+Additional information:
+
diff --git a/results/classifier/108/other/2842 b/results/classifier/108/other/2842
new file mode 100644
index 000000000..04486c6fb
--- /dev/null
+++ b/results/classifier/108/other/2842
@@ -0,0 +1,16 @@
+device: 0.661
+graphic: 0.395
+performance: 0.308
+boot: 0.307
+semantic: 0.273
+PID: 0.255
+other: 0.244
+debug: 0.165
+socket: 0.153
+network: 0.131
+vnc: 0.108
+permissions: 0.039
+files: 0.018
+KVM: 0.007
+
+RX System emulator boot, kernel images and device tree blob are missing
diff --git a/results/classifier/108/other/2843 b/results/classifier/108/other/2843
new file mode 100644
index 000000000..f6bb2b016
--- /dev/null
+++ b/results/classifier/108/other/2843
@@ -0,0 +1,48 @@
+graphic: 0.699
+device: 0.587
+semantic: 0.504
+debug: 0.504
+performance: 0.502
+other: 0.500
+vnc: 0.475
+socket: 0.412
+permissions: 0.386
+network: 0.318
+PID: 0.315
+KVM: 0.286
+boot: 0.234
+files: 0.229
+
+Strange stdin/out <-> console issue (paste problem) . May be char-win-stdio.c bug.
+Description of problem:
+I was trying to execute QEMU with VM from command line(shell) and work inside a VM within that initial console. All goes well except... pasting from clipboard. Pastings from clipboard are truncated to somewhat less (no more) then a terminal width (in columns).
+
+I understand that it seems to be far from QEMU but I tried different terminals/shells/guest systems with the same result. The only things remain the same - QEMU.
+Steps to reproduce:
+In Windows open a console (shell). Run QEMU with guest serial attached to QEMU stdio. Try to paste some text. Pasted text will be truncated to 15-35 characters. Before QEMU run and after QEMU exit text pasted normally.
+Additional information:
+-  Shell probed: **cmd**, **powershell**
+- Terminals probed: **Windows Terminal**, **Alacritty**, **Wezterm**, **Windows Terminal Preview**
+- Guest probed: **Alpine Linux**, **FreeBSD**
+- Setting inside guest probed: various terminal speed/options via **stty**
+- QEMU arguments probed: from **-nographics** to manually define **-chardev/-serial** with/without **-mon**.
+
+Finally I gave up. But want to mention that there are may be bug in source. When I tried to study source to find a hint for my issue I found that (char-win-stdio.c, line 162):
+```
+is_console = GetConsoleMode(stdio->hStdIn, &dwMode) != 0;
+    stdio->dwOldMode = dwMode;
+
+    if (is_console) {
+```
+
+Documentation of **GetConsoleMode** function says:
+```
+Return value:
+
+If the function succeeds, the return value is nonzero.
+If the function fails, the return value is zero.
+```
+
+If understand correctly **is_console** will always be _true_. It will be _false_ only in case of invalid **stdio->hStdIn**.
+
+I don't how this is related to my issue just put here all info I have in hope of resolving.
diff --git a/results/classifier/108/other/2845 b/results/classifier/108/other/2845
new file mode 100644
index 000000000..59d6515d0
--- /dev/null
+++ b/results/classifier/108/other/2845
@@ -0,0 +1,47 @@
+device: 0.812
+PID: 0.684
+performance: 0.678
+graphic: 0.662
+socket: 0.566
+network: 0.547
+vnc: 0.537
+files: 0.490
+other: 0.490
+boot: 0.461
+permissions: 0.445
+semantic: 0.418
+KVM: 0.339
+debug: 0.277
+
+memory leak in virtio-pci devices
+Description of problem:
+The Use-After-Free bug mentioned by #2440 **has not been solved**, but the same crash is not reproducable in the later versions. After reviewing the code, I found an initiailized address space `proxy->modern_cfg_mem_as` introduced by  [`55fa4be`](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/workbench.html "Inspect Commit Details") in `virtio_pci@hw/virtio/virtio-pci.c` will not be destroyed if the later realization is failed. 
+This will cause memory leak of the device object, which has unused reference and will not be destroyed.
+
+Relative Code in `virtio_pci_realize@virtio-pci.c`:
+
+```c
+/* subclasses can enforce modern, so do this unconditionally */
+memory_region_init(&proxy->modern_bar, OBJECT(proxy), "virtio-pci",
+                    /* PCI BAR regions must be powers of 2 */
+                    pow2ceil(proxy->notify.offset + proxy->notify.size));
+
+address_space_init(&proxy->modern_cfg_mem_as, &proxy->modern_bar,
+                    "virtio-pci-cfg-mem-as");
+
+if (proxy->disable_legacy == ON_OFF_AUTO_AUTO) {
+    proxy->disable_legacy = pcie_port ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF;
+}
+```
+Steps to reproduce:
+```bash
+cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0
+device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0
+device_add virtio-net,failover=on,bus=br1,id=dev0
+quit
+EOF
+```
+
+**This will cause UAF report in version `9.0.2`, but will not in `9.2.0`,** despite the bug still existing in code.
+Additional information:
+For ASAN report, please refer to #2440.
diff --git a/results/classifier/108/other/2846 b/results/classifier/108/other/2846
new file mode 100644
index 000000000..4d8b2464c
--- /dev/null
+++ b/results/classifier/108/other/2846
@@ -0,0 +1,16 @@
+device: 0.830
+performance: 0.748
+network: 0.624
+boot: 0.331
+debug: 0.309
+graphic: 0.280
+PID: 0.218
+permissions: 0.205
+semantic: 0.121
+other: 0.104
+vnc: 0.097
+files: 0.073
+socket: 0.050
+KVM: 0.033
+
+linux-user hangs if fd_trans_lock is held during fork
diff --git a/results/classifier/108/other/2847 b/results/classifier/108/other/2847
new file mode 100644
index 000000000..507800c73
--- /dev/null
+++ b/results/classifier/108/other/2847
@@ -0,0 +1,16 @@
+device: 0.846
+performance: 0.433
+graphic: 0.404
+permissions: 0.358
+semantic: 0.354
+other: 0.353
+boot: 0.345
+vnc: 0.328
+PID: 0.271
+debug: 0.239
+socket: 0.221
+files: 0.199
+network: 0.164
+KVM: 0.022
+
+Provide short option for UEFI firmware
diff --git a/results/classifier/108/other/2849 b/results/classifier/108/other/2849
new file mode 100644
index 000000000..e4d904360
--- /dev/null
+++ b/results/classifier/108/other/2849
@@ -0,0 +1,33 @@
+network: 0.899
+device: 0.706
+graphic: 0.640
+vnc: 0.621
+semantic: 0.555
+other: 0.448
+KVM: 0.433
+performance: 0.340
+boot: 0.339
+PID: 0.331
+socket: 0.271
+permissions: 0.265
+debug: 0.219
+files: 0.019
+
+Qemu 9.2.x & Ubuntu 24.04 Network Issue
+Description of problem:
+After successfully starting, I cannot access the Internet with the virtual machine. I can connect to the VM via SSH and execute various commands. We want a simple NAT network..
+
+We built the Qemu distribution ourselves with the following command:
+
+./configure --target-list=x86_64-softmmu --disable-install-blobs --enable-strip --enable-user --enable-system --enable-linux-user --disable-xen --enable-modules --enable-module-upgrades --enable-linux-aio --enable-fdt --enable-gnutls --enable-libiscsi --enable-libssh --enable-vnc --enable-kvm --enable-vhost-user
+make -j 12
+sudo make install
+
+Check Libvirt:
+$systemctl status libvirtd - active
+
+after the VM was successfully started, the IP 10.2.15 was set to ens3 altname enp0s3 assign.
+
+A ping to 8.8.8.8 can not be resolved.
+Additional information:
+We can rule out an image problem because this image runs without problems on the Windows Mac guest system and an Internet connection is possible.