Segfault in lsbom

[cluck]

Thank you for this great utility!

Unfortunately, commit 704739c introduced a segfault in lsbom, which is triggered verifying any Bom. Even the provided docker image fails to build.

I resolved the issue as follows:

diff --git a/src/lsbom.cpp b/src/lsbom.cpp
index 22d51e7..94fbb90 100644
--- a/src/lsbom.cpp
+++ b/src/lsbom.cpp
@@ -268,7 +268,7 @@ int main(int argc, char *argv[]) {

       DEBUG(2, "BOMVar 0x" << hex << ntohl(var->index) << ' ' << name << ':');

-      if (strstr(name.c_str(),"Paths") == 0) {
+      if (name.rfind("Paths", 0) == 0) {
         BOMPaths *paths = (BOMPaths *)lookup(tree->child);

         typedef map<uint32_t, string> filenames_t;

Passing c_str() pointers to standard library string functions is problematic; the C++ reference says the pointer obtained from c_str() may be invalidated by passing a non-const reference to the string to any standard library function

[hogliux]

Why are you using rfind? Wouldn't find be beter?

[cluck]

Uh, sorry for never coming back here.

I inferred from the original change that the essence still was to check for name to contain the exact string "Paths" or to start with "Paths".

-      if (name == "Paths") {
+      if (strstr(name.c_str(),"Paths") == 0) {

Note that this change effectively isn't only faulting, but it inverts the logic of the test: as it is now true when the string "Paths" is not found in name (i.e. when strstr returns NULL).

Under that assumption, rfind(.., 0) is the most efficient way to test for the string to start with "Paths", as find() would continue to search the rest of name, just to discard the result afterwards.

[cluck]

I wonder what was the motivation for the change in the first place?

[cluck]

Turns out that some BOMs carry variable names with a trailing zero and the length accounts for this additional byte. This results in name == "Paths" to fail in those cases. The proper solution is to construct name more appropriately.