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 only affects positively ancient kernels:
From (including) 3.15 Up to (excluding) 5.15.149 From (including) 6.1 Up to (excluding) 6.1.76 From (including) 6.2 Up to (excluding) 6.6.15 From (including) 6.7 Up to (excluding) 6.7.3
If I’m not mistaken, RHEL9 and equivalents are on 5.15. That’s a pretty big blast radius.
RHEL is on 5.15 in spirit only. They backport tons of patches to the point that 5.15 modules don’t build against it
Local attacker? So on your LAN
You need to be able to run code on the system that has the bug. The bug is in the netfilter component, in how it’s managed on that system, not in the actual traffic flows.
And that kids, is why we are pushing for Rust in the Kernel
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 😭😭😭
But then the kernel wouldn’t be free! Free as in ‘use-after-free’!
(/s in case it wasn’t obvious)
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)
Yay! Pick an arbitrary solution to a problem just because it’s different and shiny! The shine will fix it!
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?
Due to Rust’s ownership semantics, when we free a value, we relinquish ownership on it, which means subsequent attempts to use the value are no longer valid.
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.
Rust would not of fixed this
Rust isn’t magical
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.
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.
Do you know what a use-after-free bug is? Rust was literally designed to make this type of memory bug impossible.
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
Feeling pret-ty smug about my Windows 10 machine rn ngl
Your Windows 10 machine? Microsoft disagree.
Lol because Windows has never been exploited
Name literally one time!?
This is a joke right
