summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/performance/2149
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/zero-shot/118/performance/2149')
-rw-r--r--results/classifier/zero-shot/118/performance/214941
1 files changed, 41 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/performance/2149 b/results/classifier/zero-shot/118/performance/2149
new file mode 100644
index 000000000..b37e17bff
--- /dev/null
+++ b/results/classifier/zero-shot/118/performance/2149
@@ -0,0 +1,41 @@
+performance: 0.854
+device: 0.793
+graphic: 0.777
+network: 0.747
+peripherals: 0.740
+ppc: 0.715
+vnc: 0.670
+register: 0.668
+hypervisor: 0.658
+permissions: 0.653
+user-level: 0.645
+risc-v: 0.631
+semantic: 0.610
+VMM: 0.609
+files: 0.585
+virtual: 0.583
+arm: 0.571
+TCG: 0.570
+architecture: 0.544
+i386: 0.535
+mistranslation: 0.535
+socket: 0.532
+debug: 0.528
+KVM: 0.508
+x86: 0.500
+PID: 0.475
+kernel: 0.462
+boot: 0.436
+assembly: 0.168
+
+Segfault in libvhost-user and libvduse because of invalid pointer arithmetic with indirect read
+Description of problem:
+Hello, this is my first experience communicating with open-source community. I have already reported the problem and have submitted patches through qemu-devel mailing list https://mail.gnu.org/archive/html/qemu-devel/2024-01/msg02533.html, as instructed in https://www.qemu.org/docs/master/devel/submitting-a-patch.html, albeit getting no response from any maintainer. I know, that everyone are very busy and are spammed everyday from millions of threads, but I am getting very upset, that such a trivial bug lives in code base for many years and even have been copied to "sister"-library without proper review. So, excuse me, if I am taking this issue too personally.
+
+The problem - when one tries to use libvhost-user\libvduse and triggers for some reason non-zero-copy mode (like pushing a lot of data) of indirect descriptor reading routine `virtqueue_read_indirect_desc`, any time one got to read more than one descriptor - one would overwrite stack and depending on one's luck getting some weird behaviour, or simple crash moments later, when other code tries to access broken data.
+
+Steps to reproduce are non-trivial, because depends on one's host and VM (one simply gets random crashes here and there, with core dumps pointing somewhere around given libraries), but anyone who can read C code, can clearly see that pointer arithmetic of `struct vring_desc *desc` is wrong.
+
+Maybe, I got instructions wrong and posted fixes to wrong mailing list, maybe, nobody cares, so thank you for attention. I'll be glad to hear any advice on how can I help with fixing this simple error, besides what has been done already.
+
+Thank you.