Closed lovasoa closed 3 years ago
It may be interesting to fuzz this library with cargo-fuzz, for instance.
There is 2 aspects on this:
Looking at your example, I suspect the numrows is very high, and that coin might do some crazy allocations without checking the result, breaking everything. But I don't know what I can do about that, there is no assert that can do to check that.
For as
usage, I can change them to try_into().unwrap()
everywhere. For arithmetic, there is only 2 +1
. Can do some .checked_add(1).unwrap()
to be sure.
Using cargo-fuzz will not be very interesting: you might generate very difficult problems that takes ages to solve, blocking everything, and you will surely find bugs in coin, not in the binding.
I've run your test, and it has been killed by the linux OOM killer.
Arithmetic and conversion checks added. If you see any other possible soundness bugs that I can fix (i.e. in the bindings, and not in cbc itself), tell me. If you are OK with the result, please close the issue.
Thanks for reacting so fast !
The following safe rust program :
when running
cargo test --release
results inI tried that while poking around
coin_cbc::raw
, which seems to to some arithmetic without checking overflows, does some type casting withas
, and doesn't check for pointer aliasing. I didn't really have the time to investigate deeper, but I think there may be more memory unsafety exposed as safe rust functions in coin_cbc::raw.