Linux Gets Patched For WiFi Vulnerabilities That Can Be Exploited By Malicious Packets

[Almindor]

This is a great showcase for "if it was written in rust, none of this would happen":

• CVE-2022-41674: fix u8 overflow in cfg80211_update_notlisted_nontrans (max 256 byte overwrite) (RCE)

  • this would panic in debug mode, admittedly go through as wraparound in release mode

• CVE-2022-42719: wifi: mac80211: fix MBSSID parsing use-after-free use after free condition (RCE)

  • this would be prevented thanks to lifetime guarantees

• CVE-2022-42720: wifi: cfg80211: fix BSS refcounting bugs ref counting use-after-free possibilities (RCE)

  • this would be prevented thanks to lifetime guarantees

• CVE-2022-42721: wifi: cfg80211: avoid nontransmitted BSS list corruption list corruption, according to Johannes will however just make it endless loop (DOS)

  • this would be prevented thanks to lifetime guarantees

• CVE-2022-42722: wifi: mac80211: fix crash in beacon protection for P2P-device NULL ptr dereference crash (DOS)

  • this would be prevented thanks to lifetime guarantees in combination with no "null" (Option<T> or Result<T, E> would be used)

[ayumu]

Kind reminder there's many more of these within the kernel that we don't know about, as the kernel is huge.

Kernel bugs have the potential to crash or compromise the whole system, as the whole kernel runs in supervisor mode.

The only way around it is the adoption of a microkernel, multiserver architecture.

Contrary to common mistaken belief, this architecture does not imply a performance penalty.

[syrjala]

This is a great showcase for "if it was written in rust, none of this would happen":

On the other hand, if it was written in rust we still wouldn't have a wifi stack at all.

[NotMine999]

on the other hand, if it was written in rust we still wouldn't have a wifi stack at all.

o o f !

[sinepgib]

On the other hand, if it was written in rust we still wouldn't have a wifi stack at all.

Not meaning to shit on the people who worked on Openchrome (they're just an example that comes to mind because I followed it closely for years), but they're working in getting a KMS driver for Unichrome cards since more than a decade ago, with full documentation, in C. It took about 7 months to get one working via reverse engineering for the M1 in Rust. 2 days of debugging, according to Lina Asahi. So Rust doesn't sound like a language that would be unable to provide the tools to implement complex drivers at all.

[sinepgib]

Kind reminder there's many more of these within the kernel that we don't know about, as the kernel is huge.

Kernel bugs have the potential to crash or compromise the whole system, as the whole kernel runs in supervisor mode.

The only way around it is the adoption of a microkernel, multiserver architecture.

Yes, and yet performance and memory usage would probably be terrible for many cases (probably acceptable for the modern desktop I guess, but that's not all Linux needs to support). Meanwhile, there's tooling that may prove correctness to some degree at compile time. Not that it is one or the other in any case.

[Volta]

That's not entirely true. It only takes years because Windows system maintainers don't bother to update.

Remember 'famous' desktop icons bug? It took them nearly year to fix.

[Volta]

The only way around it is the adoption of a microkernel, multiserver architecture.

Whats's so huge? Thousands of drivers you're not using? There's no way around, because microkernel is no go. If you want wasting hardware it's better to burn it instead using slow piece of crap like microkernel. There's a reason none of the relevant OS's is using microkernel. There's also reason why Tannenbaum wasted his life, because of dumb idea while Torvalds succeeded.

[Sergey Podobry]

This is a great showcase for "if it was written in rust, none of this would happen"

Actually any modern language is safer than C. Even in C++ you can avoid this kind of errors.

[Jannik2099]

This is a great showcase for "if it was written in rust, none of this would happen":

It's worse than that. As Sergey said even C++ back then would've prevented this. Also, some of the code was using -Wno-array-bounds, a flag that Torvalds explicitly allows. Similarly, the kernel is full of -fno-delete-null-pointer-checks, a flag that Torvalds refused to fix multiple times.

The kernel is written in a terrible language, but we are also not making use of many existing static analysis methods because Torvalds does not deem it necessary. Adopting Rust is great, but it can't fix the existing code, and it can't fix the flawed leadership.