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.
And that kids, is why we are pushing for Rust in the Kernel
But then the kernel wouldn’t be free! Free as in ‘use-after-free’!
(/s in case it wasn’t obvious)
But… You dont understand, Rust is the devil! If Rust were made the kernel’s main language it would terrible because that would mean change 😭😭😭
Magical pills do not exist. Better start pushing old fuckers incapable of learning out of the project (yeah, I don’t like this kind of treatment of Rust just because it is not C either)
Lol. You have no idea what you are talking about about here 😂
Granted, I was mostly shit posting. But in all seriousness: wouldn’t Rust prevent that kind of exploit by inherent design?
https://stanford-cs242.github.io/f18/lectures/05-1-rust-memory-safety.html
Yes, that’s right. You cannot have a UAF situation unless you’re using unsafe “escape hatch” tools.
Again… IMPROBABLE
I’ve only seen it once. And it was made specifically to trigger a compiler bug. It barely looked like rust code.
Now tell me how someone will introduce such a bug by accident. Winning the lottery 10000 times in a row with the same number isn’t impossible either. But we are engineers, not pure math pedantics. 0.000000000000001% probability for something that happens with less frequency than once per second is impossible.
C++ would also solve this for the same reason!!
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.
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.
Okay, then why we need to use a language that has more in common with OCaml? What about using a better C instead?
Such as?
no one uses d
Rust would not of fixed this
Rust isn’t magical
Do you know what a use-after-free bug is? Rust was literally designed to make this type of memory bug impossible.
You never say “would not of”. It’s “would not have”.
Rust would have prevented this, because the borrow checker prevents use-after-free vulnerabilites.
Explain how a use after free could occur in safe rust, because to my knowledge, that is exactly the kind of thing rust does protect against.
Easy. Do some specific incantation that barely looks like it follows rust syntax that is specifically made to exploit a bug in the rust compiler.
Yay! Pick an arbitrary solution to a problem just because it’s different and shiny! The shine will fix it!