now it's even more battle tested!

Let's rewrite everything - said every 15 minutes by every new developer with a new toy.

How about being constructive instead - old bug in old code is no surprise, no matter the language/technology.

The key difference is even If an Integer overflows in Rust It still doesn't violate memory safety in safe Rust and therefore doesn't lead to exploitation.

The integer overflow issue is only part of the problem. There are a couple underlying issues that make this exploit feasible: certain regexes produce extremely long bytecode, the integer overflow issue, and finally, a double free.

Rust will not protect you against exploding regexes, it will not protect you against integer over/underflows (unless you specifically call safe wrapping methods), but it will protect you against double frees if you use it sensibly (nothing prevents you from breaking the borrow checker and messing up memory if you write an unsafe {} block).

[profile.release] overflow-checks = true

> but I do hope the C projects will preemptively start fuzzing

One of the points I wish more people understood about fuzzing is what it is doing is grabbing a random selection of all the possible inputs and running them through the function (Yes the fuzzer can be made to target/exercise different branches in the code, but it's still doing that with a random selection of the possible inputs that will exercise said piece of code).

Fuzzers miss bugs, because the full corpus of possible inputs is impossible to permutate through every function.

But the advantage of fuzzers is that they choose inputs that developers never think to try on the code.

edit: some back of the envelope AI math:

To enumerate every unique state of a 64-bit variable, you must iterate through 18,446,744,073,709,551,616 individual inputs (2⁶⁴).

The exact time in seconds depends entirely on the processing speed of the system executing the loop. Here is how the time breaks down across three different performance levels:

1. Standard Desktop CPU (1 Billion operations/sec)

• Time: 18,446,744,073 seconds

• Scale: Roughly 584.5 years

• Context: If a single core on a modern processor handles roughly 1 billion state evaluations per second (1 GHz efficiency), it would take nearly six centuries to finish.

2. High-End Multi-Core Processor (4.3 Billion operations/sec)

• Time: 4,294,967,296 seconds

• Scale: Exactly 136.1 years

• Context: If you maximize a consumer CPU utilizing multiple threads or an incredibly high single-core instruction-per-clock rate (4.29 GHz efficiency), it still takes well over a human lifetime.

3. High-End Enterprise GPU / Supercomputer Cluster (1 Trillion operations/sec)

• Time: 18,446,744 seconds

• Scale: Roughly 213.5 days

• Context: A highly optimized, massively parallel hardware setup—like an enterprise GPU cluster capable of churning through 1 Terahash/Tera-iteration per second—can shrink this problem down to a matter of months.