On 09/09/2014 03:36 AM, Wang Rui wrote:
On 2014/9/5 6:26, John Ferlan wrote:
If the virJSONValueNewObject() fails, then rather than going to error and getting a Coverity false positive since it doesn't seem to understand the relationship between nkeywords, keywords, and values and seems to believe calling qemuFreeKeywords will cause a NULL deref - just return NULL
Signed-off-by: John Ferlan <jferlan@redhat.com> --- src/qemu/qemu_monitor_json.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 62e7d5d..b0bc5fc 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -617,7 +617,7 @@ qemuMonitorJSONKeywordStringToJSON(const char *str, const char *firstkeyword) size_t i;
if (!(ret = virJSONValueNewObject())) - goto error; + return NULL;
Maybe it's not enough.
if (qemuParseKeywords(str, &keywords, &values, &nkeywords, 1) < 0) goto error;
Here, qemuParseKeywords() may fail and 'values' is still NULL.
Yes, but for some reason once qemuParseKeywords() is called Coverity has "resolved" that things will be OK. This one is a false positive and perhaps a bug in the Coverity parser. The return NULL is the way to avoid the condition. Filing a Coverity bug is an option, but changing the logic is just quicker. I think it gets flagged because Coverity perhaps prescans the code and "flags" all callers to qemuFreeKeywords as potentially having a FORWARD_NULL. It doesn't seem to pick up the fact that nkeywords is initialized to 0 (along with keywords and values being set to NULL). It's perhaps focusing on the array addresses rather than the logic of using nkeywords to access those arrays. John