this post was submitted on 03 Nov 2025
163 points (97.7% liked)

Linux

13788 readers
219 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 2 years ago
MODERATORS
MigratingtoLemmy@lemmy.world
163
CISA Warns of Linux Kernel Use-After-Free Vulnerability Exploited in Attacks to Deploy Ransomware (cybersecuritynews.com)
submitted 1 day ago by RegularJoe@lemmy.world to c/linux@lemmy.world
70 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] turdas@suppo.fi 1 points 23 hours ago (1 children)

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::move a 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.

[–] sp3ctr4l@lemmy.dbzer0.com 3 points 21 hours ago (1 children)

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.

[–] turdas@suppo.fi 1 points 14 hours ago (1 children)

If you follow modern C++ best practices, memory unsafety will not happen by accident. The dodgy stuff in modern, idiomatic C++ is immediately obvious.

[–] sp3ctr4l@lemmy.dbzer0.com 1 points 13 hours ago (1 children)

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.

[–] turdas@suppo.fi 1 points 13 hours ago* (last edited 13 hours ago)

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.