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.