blob: d14d8bda41e61322ea3c389b11f1f132ab14a081 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
vnc: 0.874
graphic: 0.874
instruction: 0.774
socket: 0.685
semantic: 0.658
network: 0.653
device: 0.642
other: 0.509
boot: 0.374
KVM: 0.248
mistranslation: 0.231
assembly: 0.206
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.
|