[ncw33]

It's good for the library to be robust, but four code cleanliness issues (not triggerable remotely) hardly counts as news in the world of vulnerabilities!

Keep them coming, I'm glad that so many of us who use mbedTLS are reporting these little issues and getting a better library (with an excellent track record of very few serious problems).

[guidovranken]

There are not code cleanliness issues. These are all public API functions. Whether any of these bugs can be triggered remotely depends on the application and which API functions it chooses to expose to untrusted data (or how it deals with the results of the multi-precision integer functions). From the limited number of open-source projects that use mbed TLS, it's difficult to gauge how widespread the overall use of these functions is. That said, you are right in saying that it they are not critical in the sense that they are reachable through the library's public-facing TLS state machine.

[briansmith]

You can probably find the same or similar bugs in lots of crypto libraries. I occasionally fix similar issues in ring and BoringSSL so that the BoringSSL/LibreSSL/OpenSSL/ring community can discover and fix the issues.

Arguably, the real bug is that these crypto libraries even try to represent negative numbers at all in the first place. In ring I'm close to removing all support for negative numbers.