Coverity Scan flags some possible issues

[nemequ]

Coverity Scan flags 3 issues in liblzg with may be real. If you want, I can invite you to view the report for Squash in Coverity (detailed results are not public), where they have a handy annotated view of the source code explaining exactly how the tool arrived at the conclusion it did. Or you could create a project for liblzg. Two of the issues may have security implications (one of them is just a warning about dead code), so I'm not sure you want me to describe them here, though if you want I can.

[mbitsnbites]

Hello @nemequ - thanks for the work. I'm perfectly fine with an issue report (or if it's trivially fixed - a pull request).

[nemequ]

Okay, the first one isn't really significant, just some dead code. The condition at encode.c:599 will never be true (sa isn't assigned to until line 445, and that is also the last place goto fail; is used, but only if !sa.

After looking at it closer, the second one (decode.c:217, length is derived from the input so the bounds of the loop can be controlled by the data) seems to be a false positive, as it is restricted to a table of preset values.

The third one I think requires a bit more familiarity with the code to know whether it is an issue. Coverity sees the assignment to lldx on encode.c:292 as a byte swapping operation, so assumes it came from an untrusted source and marks it as tainted. Then, the tainted value is used as an array offset on line 294, which means the input could control the array index used on line 294, potentially allowing it to load data from an unintended address.