LGTM.com - false positive cpp/uncontrolled-allocation-size

[rsmarples]

This code calculates an allocation size by multiplying a user input by a sizeof expression.

Firstly, there is no multiplication of any user input in play.
All we are doing is making a duplicate of the packet we received.
The upper bound is also checked on line 3451 which I added just to try and curcumvent this issue. The code can receive the packet from 3 different sources, but they all will hit this line before any attempt to duplicate the packet is made.

In the cases where there is multiplication in play in dhcpcd, we use the function reallocarray from BSD libc which your example should use anyway.

URL to the alert on the project page on LGTM.com

https://lgtm.com/projects/g/rsmarples/dhcpcd/snapshot/e7f194885e43765a5d6cae01fd7fa30e075843cd/files/src/dhcp.c?sort=name&dir=ASC&mode=heatmap#x4eac3e1b4fba2f35:1

[sandsmark]

Does it get happier if you do the len check right before instead?

It could be finding a non-obvious path (and assuming the length is checked in another function seems like something that might be easy to forget), so it might be intended behavior?

[jbj]

This issue looks related to #2762, so I'll assign to @geoffw0.

[rsmarples]

Does it get happier if you do the len check right before instead?

It could be finding a non-obvious path (and assuming the length is checked in another function seems like something that might be easy to forget), so it might be intended behavior?

Even if I do duplicate the check at every receive call, how would I solve the same false positive here?
https://lgtm.com/projects/g/rsmarples/dhcpcd/snapshot/6e56ded48ea5c4330e318b5b023b1feed938d1f1/files/src/auth.c?sort=name&dir=ASC&mode=heatmap#x99f91a80b6d74e41:1

There is no operations on key_len - it's set perfectly fine when parsing the options (either from a config file or on the command line) and LGTM does not complain about that. But here - again - we are just making a copy of what we already have.

I've been through all 12 alerts and as best I can tell they are all false positives.

[rsmarples]

So here we are again :)
While the above alerts are no longer reported (yay, thanks!), here are two new ones:

https://lgtm.com/projects/g/rsmarples/dhcpcd/snapshot/7321f8d4812fa0bbe7daccd3391e85aa4bb01de6/files/src/privsep-root.c?sort=name&dir=ASC&mode=heatmap#x2ac2a2f5a5efa5e6:1
https://lgtm.com/projects/g/rsmarples/dhcpcd/snapshot/7321f8d4812fa0bbe7daccd3391e85aa4bb01de6/files/src/dhcpcd.c#xcf7feddb40e681af:1

In the code, both sizes are from user input, both are guarded by ensuring <= SSIZE_MAX, neither have any addition or multiplication but LGTM still warns which I believe is a false positive.

[jbj]

Thanks the the updated report. I've added it to our backlog of issues with this query.

[jbj]

Thank you for your patience with this issue. We won't get to the bottom of this in the near future, so we've now lowered the precision of the query so it's not displayed by default on LGTM. The change will take effect on the next deployment to LGTM, which should happen in 2-4 weeks from now.