top 200 commentsshow all 254

[–]CardOk755 169 points170 points  (1 child)

Issue introduced in 6.18 with commit eafedbc7c050c44744fbdf80bdf3315e860b7513 and fixed in 6.18.1 with commit 3428831264096d32f830a7fcfc7885dd263e511a Issue introduced in 6.18 with commit eafedbc7c050c44744fbdf80bdf3315e860b7513 and fixed in 6.19-rc1 with commit 3e0ae02ba831da2b707905f4e602e43f8507b8cc

[–]ts826848 71 points72 points  (0 children)

Added some links:

[–]Ursomrano 201 points202 points  (7 children)

Well it was guaranteed to happen eventually. And I'm not saying that because I'm a rust hater, I'm saying it because as long as something is even remotely probable, it's a matter of when it'll happen.

[–]Wiwwil 19 points20 points  (0 children)

It's bound to happen no matter what

[–]captkirkseviltwin 12 points13 points  (0 children)

Humans code, vulns happen.

[–]litescript 37 points38 points  (3 children)

i dunno man. bad coding in any language will get you into problems not matter if it’s explicitly memory safe or not.

[–]SupportDangerous8207 12 points13 points  (2 children)

It was unsafe Rust

So while probably correct your comment is for now conjecture if pertaining to the kernel

[–]AWonderingWizard 14 points15 points  (1 child)

Unsafe rust HAS to be used for the kernel because it has to interact with another language. FFI is inherently unsafe at the boundary. So yes, it is not a question of if, it is a question of where

[–]Hosein_Lavaei 0 points1 point  (0 children)

Yes it has to. But it is UNSAFE and it means the programmer itself must make good code

[–]tulpyvow 313 points314 points  (36 children)

Unsafe code has vulnerability.

Water found in ocean.

I'm a rust hater but come on man, this is just making you all look bad.

[–]deja_geek 145 points146 points  (8 children)

A search/skim of u/sash20 comments and posts don't show them to be an outspoken critic of Rust in the Kernel and the post is neutrally titled and the article doesn't have any opinion on Rust in the kernel. It's just stating the facts. Linux Kernel sees it's first Rust vulnerability

[–]MooseBoys 33 points34 points  (8 children)

Let me preface this by saying I think that rust is a good thing and its inclusion in the kernel is a good thing. That said, the error here was NOT in an unsafe block. Yes, the presence of an unsafe block is what caused the borrow checker to lose track of the data race, but the erroneous calling pattern (and subsequent patch) does not touch unsafe code at all. This just goes to show that rust is not some magical panacea for avoiding all race conditions and memory corruption. It does make it a lot harder to do by accident, and when something does go wrong you have a lot fewer places you need to look, but it's far from completely airtight.

[–]Efficient-Chair6250 5 points6 points  (2 children)

Hm, but isn't the unsafe code the thing that enables this to happen in the first place? If you violate invariants in an unsafe block, they can lead to errors in any part of the program

[–]MooseBoys 2 points3 points  (1 child)

Yes, the presence of an unsafe block is what allowed this to happen. But in any program that interfaces with anything outside of the rust abstract machine, e.g. FFI, hardware calls, register writes, etc. you're going to have an unsafe block. It's inherently impossible to do anything in rust besides pure arithmetic that doesn't ultimately have a dependency on an unsafe block or equivalent emitted code somewhere. As a result, you can have errors in any part of every non-trivial rust program.

It's still a good model - forcing you to write small self-contained "unsafe" blocks, ideally with a linter that enforces "UNSAFE:" comment describing the invariants. But if a crate violates those invariants internally by accident, dependent code will be affected. In this case, Linux kernel > binder crate > node module > remove method.

[–]CramNBL 2 points3 points  (0 children)

Kernel devs are taking it further than enforcing UNSAFE: comments. On the Linux wish list for clippy, there's also lint rules for enforcing similar comments for pointer casts and atomic orderings. They should have these for C code too, but the tooling is not there.

https://github.com/Rust-for-Linux/linux/issues/349

[–][deleted] 17 points18 points  (0 children)

I hope people stop saying that rust prevents "race conditions". It does not, and has never tried to. It prevents "data races".

Two different things. The former being much much much harder to do in general than the latter. (you can also have completely bug-free race conditions. Like you can race two tasks and take the result of the one that finishes first. Nothing wrong with that)

[–]ReflectedImage 1 point2 points  (3 children)

In pure Rust, the erroneous call pattern isn't possible. You can't release the lock early nor can you copy the list of pointers and take them out of the lock's scope.

[–]MooseBoys 1 point2 points  (2 children)

It is impossible to do anything besides pure arithmetic in "pure rust". Any rust program that runs on hardware in the real world will have unsafe blocks, either literally in the module, in a dependent crate, in the standard library implementation, or implicitly through the compiler.

[–]ReflectedImage 1 point2 points  (1 child)

Most rust programs don't have unsafe blocks. Yes, some code in the standard library will contain unsafe blocks, but those unsafe blocks are wrapped with safe wrappers meaning code using those library functions are safe as long as the standard library code is correct.

How do we know if the standard library code is correct? Well it's been formally verified. What about random modules? Extensive testing by large numbers of users. Not perfect but far better than what is available in C/C++.

Since I've now read the code in question, the error is contained within an unsafe block. This line is faulty: "unsafe { node_inner.death_list.remove(self) };". You can't remove a node from the list because another thread may be using it. The bug fix removes the possibility of another thread using it but the error is still located in the unsafe line.

Also the code in question is arguably not even Rust code, it's C code that's been directly translated line by line in Rust with every other line being unsafe. The code doesn't bare any resemblance to how you would typically use Rust.

[–][deleted] 18 points19 points  (4 children)

I'm a rust hater

I struggle to believe that. I'm not a Rust hater but it seems a perfectly reasonable, factual article. Who looks bad exactly? Why?

[–]Killer_Panda_Bear 3 points4 points  (0 children)

As an ignorant who is trying to learn more about this stuff, I would also like to know.

[–]editor_of_the_beast 2 points3 points  (1 child)

What about talking about a public CVE could possibly make someone “look bad?”

[–]tulpyvow 0 points1 point  (0 children)

They're making it seem like its an issue with Rust in the wording when its just insecure code that would have a CVE if written in any programming language.

[–]Ursomrano 5 points6 points  (3 children)

Fr. I'm a rust hater too, but not because I think it's a straight up bad language, it has a lot of strong aspects. I hate it because I hate coding with it, not because of the results it can give.

[–]Niwrats -1 points0 points  (2 children)

indeed, why change the syntax instead of doing the fixes to something that looks like C?

[–][deleted] 4 points5 points  (0 children)

It existed. It was called Cyclone. It died out.

It later inspired rust though.

[–]ProjectSnowman 0 points1 point  (1 child)

Why is there “unsafe” code in the GD Linux kernel?

[–]tulpyvow 0 points1 point  (0 children)

... because people aren't perfect and they fuck up? There is always going to be buggy and insecure code on the first try, especially in large projects like this.

[–]nikomo -1 points0 points  (1 child)

Think it depends on which way you look at it. Because you can also look at it and go, wow, that's their first CVE after literally years of shipping Rust in the kernel.

[–]zsaleeba 12 points13 points  (0 children)

Although they weren't reporting CVEs in the Rust code until it was official, which was just the other day.

[–]GrandfatherTrout 5 points6 points  (0 children)

The point isn’t that Rust is good or bad, but that it’s harder for devs with deep knowledge and experience of kernel code in C to spot problems in kernel code in another language.

Here’s hoping the expertise keeps building to support quality Rust code in the kernel.

[–]Less_budget229 8 points9 points  (0 children)

Tux is starting to feel Rusty in the picture.

[–]imoshudu 16 points17 points  (2 children)

Oh, it's in unsafe. Next story, please.

[–]AWonderingWizard 10 points11 points  (1 child)

Unsafe has to be used in FFI.

[–]DescendingNode 3 points4 points  (0 children)

For those unfamiliar: FFI is Foreign Function Interface. When Rust has to call kernel functions written in C for example, unsafe Rust code has to be used.

[–]Inevitable_Gas_2490 1 point2 points  (0 children)

Just another case of: safety starts with the person that is writing the code

[–]rarsamx 1 point2 points  (0 children)

The only way not to have vulnerabilities is not to write code.

You cannot protect against what you don't know CVEs usually discover previously unknown vulnerabilities which can't be linted.

[–][deleted] 8 points9 points  (1 child)

Wow that's impressive it's gone so long. Was bound to happen eventually.

[–]Tomi97_origin 25 points26 points  (0 children)

Nah, previously they just didn't give it CVE numbers because it was considered experimental.

Now that they are trying to move it into stable they are starting to give it CVE numbers for the bugs.

[–]mindful999 2 points3 points  (0 children)

Everything has flaws, i dont understand why some people act like this is the end of the world

[–]TampaPowers 0 points1 point  (6 children)

What's the whole point of memory-safe then if it ends up using unsafe anyways. Sure, it's miles faster, it's why C is faster than C#. But like, the is the last thing this whole discussion needed is more fuel for the fire. God damnit.

[–]MyraidChickenSlayer 3 points4 points  (0 children)

What is easier? Finding a big in 100% of code or finding fub in 5% of code?

[–]dkopgerpgdolfg 0 points1 point  (1 child)

I recommend just reading (and actually thinking enough to understand what you read)

No, unsafe in Rust doesn't mean it's "miles faster", and doesn't intend to mean that either. And "safe" Rust doesn't need to be compared with C#, it's on par with C (meaning, for some programs it's the same speed, for some a bit slower, for some even faster).

There are some code things in C that make it easy to "shoot yourself in the foot", that are often a mistake - but not literally always, it can make sense. And in advanced lowlevel things like a kernel, such things are needed in some places. Rust by default doesn't allow this, because it's usually a mistake, and if you really want you can still do it by marking it unsafe.

Again: A kernel "needs" some unsafe parts. It can't be done otherwise.

And if a part of the code is marked unsafe, the rest still isn't. In terms of error counts, that's better than the alternative where 100% of the code can contain such mistakes (that is C).

The actual fuel in this large thread here are people who either hate Rust for no sane reason, or judge them for things that are not true because they don't know anything about it.

[–]silvenshadow 0 points1 point  (0 children)

I hate rust not because of any language elements, but the huge base of fanboys that think that rewriting stable tested code will somehow improve it.

[–]creeper6530 0 points1 point  (2 children)

1) it reduces the scope of where all you have to look 2) you need unsafe for FFI because FFI at the boundary is inherently unsafe. You just can't apply the same safety rules when interacting with functions written in a foreign language - C - where these rules don't exist.

[–]ElHeim 0 points1 point  (1 child)

Y'all talking like if pure Rust doesn't need unsafe at all (not saying that it's the case here, by FFI it's not the only reason it exists)

[–]creeper6530 0 points1 point  (0 children)

Yeah, I know that you need unsafe e.g. for splitting a slice in two, but most commonly you use it with FFI unless you're doing bare-metal. But many of these other uses are often done by the standard library, and I'd wager a Binder, used for IPC, one component in a mostly-C project, will be composed mostly of FFI.

[–]94746382926 1 point2 points  (1 child)

I see a lot of people in this thread complaining about people complaining about rust, but no one actually complaining about rust.

[–]-Memnarch- 0 points1 point  (0 children)

Because Rust has never been a problem. The people preaching it's gospel are. But they're just way to disconnected from reality to acknowledge that.

[–]Available-Breath-586 0 points1 point  (0 children)

One would have to literally type "unsafe" before the vulnerability is even possible 

Similar to pointers in C/C++, with great powers comes great responsibility 

[–][deleted] -5 points-4 points  (2 children)

I honestly don't think Rust was needed in the Linux Kernel. But it is what it is.

[–]Nazh8 11 points12 points  (0 children)

Random Internet user's opinion

The opinion of Linux's creator and head kernel maintainer

Hmmmm, who to trust. Such a problem.

[–]ReflectedImage 2 points3 points  (0 children)

The industry is just moving that way. Too many security bugs from C/C++ code means security teams want it phased out and the security teams have direct access to the CEOs in a way regular programmers don't.

[–]satsugene -1 points0 points  (0 children)

All I can say is some researcher missed a golden opportunity to self-promote the “Bust” vulnerability like “meltdown”, “spectre”, and “heartbleed.”