Found by Coverity. Because there's an "if ((cur = strstr(base, "revision"))
!= NULL) {" followed by a "base = cur" coverity notes that 'base' could
then be NULL causing the return to the top of the "while ((tmp_base =
strstr(base, "processor")) != NULL) {" to have strstr deref a NULL 'base'
pointer because the setting of base at the bottom of the loop is unconditional.
Alter the code to set "base = cur" after processing each key. That will
"ensure" that base doesn't get set to NULL if both "cpu" and "revision"
do no follow a "processor".
While a /proc/cpuinfo file that has a "processor" key but with neither
a "cpu" nor a "revision" doesn't seem feasible, the code is written as if
it could happen, so we have to account for it.
Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
---
src/util/virsysinfo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c
index 14c17a8..8d3377c 100644
--- a/src/util/virsysinfo.c
+++ b/src/util/virsysinfo.c
@@ -231,6 +231,7 @@ virSysinfoParsePPCProcessor(const char *base, virSysinfoDefPtr ret)
if (eol && VIR_STRNDUP(processor->processor_socket_destination,
cur, eol - cur) < 0)
return -1;
+ base = cur;
if ((cur = strstr(base, "cpu")) != NULL) {
cur = strchr(cur, ':') + 1;
@@ -239,6 +240,7 @@ virSysinfoParsePPCProcessor(const char *base, virSysinfoDefPtr ret)
if (eol && VIR_STRNDUP(processor->processor_type,
cur, eol - cur) < 0)
return -1;
+ base = cur;
}
if ((cur = strstr(base, "revision")) != NULL) {
@@ -248,9 +250,9 @@ virSysinfoParsePPCProcessor(const char *base, virSysinfoDefPtr ret)
if (eol && VIR_STRNDUP(processor->processor_version,
cur, eol - cur) < 0)
return -1;
+ base = cur;
}
- base = cur;
}
return 0;
--
2.9.3
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
