This vulnerability, hidden within the netfilter: nf_tables component, allows local attackers to escalate their privileges and potentially deploy ransomware, which could severely disrupt enterprise systems worldwide.
This vulnerability, hidden within the netfilter: nf_tables component, allows local attackers to escalate their privileges and potentially deploy ransomware, which could severely disrupt enterprise systems worldwide.
If this is a joke, I don’t get it
It’s not a joke. What was described above is pretty much C++'s RAII pattern, which Rust evangelists love to present as a revolutionary Rust invention. Used with smart pointers, it will help avoid use-after-frees. What it doesn’t avoid is null pointer exceptions (you can
std::movea unique_ptr and still access it, it’ll just be nullptr), but those will typically “just” be a crash rather than a gaping security hole.That is not to say Rust doesn’t have its own innovations on top of that (notably that the compiler stringently enforces this pattern), and C++ does give you many more ways to break the rules and shoot yourself in the foot than Rust does.
Your second half there is the whole point.
Being memory unsafe in C++ is can occur by accident.
Being memory unsafe in Rust… essentiallly requires consistent intent.
When coming up with guidelines for an emgineering procesd that can go catastrophically wrong… do you use a stricter ruleset, or a less strict one?
That’s basically the safety argument.
If you follow modern C++ best practices, memory unsafety will not happen by accident. The dodgy stuff in modern, idiomatic C++ is immediately obvious.
I would love to see a study about people that follow C++ best practices. Put a bunch of C++ devs and tell them to write some programs. Then see how many of those programs would be valid according to rust’s borrow checker.
Whatever % of people that “fail” this test, is much higher than the 0% of people that would do so using rusts’ compiler.
Of course, programs that don’t pass the borrow checker can be totally memory safe, but that would need to be analyzed on a case by case basis.
Programs that do pass the borrow checker aren’t guaranteed to be totally memory safe, so the number isn’t actually 0% for Rust either: https://github.com/Speykious/cve-rs
Yes but the whole point is that Rust forces you to do this.
Not everybody follows best practices, sometimes people who say they do, well they make mistakes.
I really don’t understand how this is conceptually difficult to grasp.
Rust forces you to do this until you have to use unsafe, after which it doesn’t. That is not so different from C++ guaranteeing your safety until you start using raw pointers.
It is not the compiler’s job to stop the programmer from shooting themselves in the foot if they want to. It’s the compiler’s job to make it clear to the programmer when they disable the safety, put their finger on the trigger and aim the gun at their foot. Modern C++ does this, and if you still inadvertedly shoot yourself in the foot in spite of the warnings, you brought it on yourself.
Regular old C, on the other hand, gives you a 9mm when you’re in grade 7, safety: always off.
I think the idea is that it’s easier to manage your resources in C++ if you write your code using RAII. Linux is mainly C, not C++, which makes resource management a little bit more manual.
Rust however categorically tries to stop these problems from happening in an even stronger way. You can still write bad code in any language, but it’s supposed to be a lot more difficult to get memory corruption.