blob: 5f7512b7d016c3826e3c1a40b7d1e63540c353be (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
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.
|