1 files changed, 45 insertions, 0 deletions
diff --git a/results/classifier/118/vnc/2311 b/results/classifier/118/vnc/2311
new file mode 100644
index 000000000..c7a46c2b2
--- /dev/null
+++ b/results/classifier/118/vnc/2311
@@ -0,0 +1,45 @@
+vnc: 0.874
+graphic: 0.874
+ppc: 0.857
+performance: 0.799
+socket: 0.685
+semantic: 0.658
+network: 0.653
+permissions: 0.643
+device: 0.642
+register: 0.619
+architecture: 0.584
+VMM: 0.580
+kernel: 0.574
+files: 0.492
+peripherals: 0.480
+debug: 0.480
+risc-v: 0.424
+boot: 0.374
+TCG: 0.368
+hypervisor: 0.342
+x86: 0.334
+PID: 0.317
+i386: 0.289
+arm: 0.284
+KVM: 0.248
+mistranslation: 0.231
+assembly: 0.206
+user-level: 0.191
+virtual: 0.145
+
+Possible dereference of NULL
+Description of problem:
+There is possible dereference of NULL using macro QEMU_LOCK_GUARD(&q->lock) in:
+1) /block/nvme.c line [326](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/block/nvme.c#L326)
+2) /include/qemu/ratelimit.h line [45](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L45)
+3) /include/qemu/ratelimit.h line [88](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L88)
+
+
+The QEMU_MAKE_LOCKABLE(x) macro provides a special case (line [71](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L71) of the lockable.h) if NULL gets into it. Then the macro will return NULL, which will get to the input of the qemu_lockable_auto_lock() function, then to the qemu_lockable_lock() function, where NULL dereference will occur (line [95](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L95)).
+
+It turns out that the NULL case is provided, but not handled properly. I think a NULL check should be added.
+
+Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
+
+Author A. Burke.