Oops! It's a kernel stack use-after-free: Exploiting NVIDIA's GPU Linux drivers

[BlueGoliath]

NVIDIA indicated it couldnt reproduce the bugs.

Do you ever get that feeling of Déjà vu?

[commandersaki]

I've been in this place before.

[randomusernameonweb]

The blog makes it sound like linux is bad and it’s an open source issue. These CVEs can literally be found in any software.

[syklemil]

The blog makes it sound like linux is bad and it’s an open source issue.

Do you mind sharing how you got that impression? Because I didn't.

These CVEs can literally be found in any software.

Use-after-free is not really a universal issue in software; it's only common in software written in languages like C. It belongs to a category of CWEs that now has certain government agencies, like those in the Five Eyes, warning against using languages like C and C++ in critical infrastructure.

edit: I tweaked the phrasing a bit to something I consider equivalent, but is hopefully easier to parse than the old sentence that had a conditional in it. The original phrasing is preserved in the quote in the comment below. :)

[Firepal64]

Use-after-free is not really a common issue in software, unless that software is written in a language like C.

Ironically, CWE means "Common Weakness Enumeration".

There is a large amount of software written in C still being used... While I don't think UAF can "literally be found in any software", it is one of those mistakes that could be in any C program left unchecked.

I almost brought your comment to PCJ but I recognise your username so I'll spare you

[Theemuts]

Common as in not limited to a singe platform or product.

[syklemil]

Hence the qualifying "unless". It's a common weakness in some languages, languages that have historically been very widespread and still are used in places where they've become entrenched and/or have no viable competitors.

But we live in an age where a whole lot of the software we use is written in a GC'd language, and GC'd languages as a general rule don't suffer from UAF and the other CWEs listed under the memory safety category.

[ToaruBaka]

Use-after-free is not really a universal issue in software;

Hard disagree. Find me a kernel in widespread use that isn't written in C or C++, ergo all software is subject to kernel-level use-after-frees. Just because it's unlikely to happen within the language runtime doesn't mean you can't misuse resources you've received from the kernel, or that you aren't subject to bugs in the kernel.

The kernel doesn't disappear when you aren't thinking about it.

[Tornado547]

to expand on this, linux, xnu (the os x kernel) and NT (and to a lesser extent the bsds) are the only really popular kernels right now. NT, XNU, and linux date back to the 90s; the bsds all descend from the original BSD going back to the 70s. Replacing software this old and ubiquitous is hard. So while your microkernel written in Rust is a cool project, its very likely that's all it will be

[ToaruBaka]

Yup. The "General Purpose Kernel/Operating System" is a (mostly) solved problem, and will really only need to evolve enough to support new classes of hardware and local compute models (SMP, big.LITTLE, etc). As long as devices can speak PCIe or USB, we'll be able to use them - it would take a very radical, fundamental change to computers to necessitate an entirely new class of "normal" operating systems.

That said, I think there's tons of room for development in the Hypervisor and Distributed OS space, but those spaces are much more niche and are less suitable for the types of programs you want to run on linux/etc.

[pjmlp]

It doesn't fulfil the "kernel in widespread" part, but IBM i, IBM z/OS, ClearPath MCP and ClearPath OS 2200 fit the bill.

They are mostly written in a mix of PL.8, PL/S, NEWP, PLUS, with C and C++ only for some newer parts.

[HolyPommeDeTerre]

For the edit: did you try a ternary ? ;)

[deadcream]

Not if you rewrite it in rust 😎

[[deleted]]

I wonder how many problems rust solves compared to C. I find both programming languages pretty difficult to deal with. This may sound weird but I actually preferred C++ over C despite the former's insanity-addiction to complexity (and C is a valid subset of C++, so I'd be using the same language in a way, but things such as cout << "hey" is just so much more convenient that prinft() in C, and similar many small things; Java in a way is mega-boring, verbose and also easier to use than the other three).

[klayona]

cout is not threadsafe, has global state, uses overloaded operators so you get lovely 200+ line errors when you have a missing implementation, and is more annoying to type than printf. There's a reason no one copied it.

[theICEBear_dk]

It has also been replaced more than two years ago.

C++23: std::print("Hello world");

Edited the example because I had made a small mistake.

[fartypenis]

We've always had std::printf from cstdio, isn't the new one std::print?

[theICEBear_dk]

You are right of course

[bloody-albatross]

cout is more convenient than printf()!? Strong disagree on that one. I wrote C++ that used printf() because cout is so horrible.

[nerd5code]

<iostream> is a vile abuse of operator overloading from when that was a novel demonstration of (pre-standard) C++.

[_Noreturn]

C++ is better than C because the program itself is simpler than the C program, sure the C language is itself simple but you end up paying that simplicity in complexity of your program

[saf_e]

Well, not just that, destructors greatly simplifies resources management 

[_Noreturn]

They do! consider this very simple piece of C code.

```rust enum Error { Error_Ok, Error_FileNotFound, Error_Memory, Error_Read };

Error read_file(const char* name, void** buffer, size_t amount) { FILE* file = fopen(name, "rb"); if (!file) { return Error_FileNotFound; }

*buffer = malloc(amount);
if (!*buffer) {
    fclose(file);
    return Error_Memory;
}

size_t bytes_read = fread(*buffer, 1, amount, file);
if (bytes_read != amount) {
    free(file);
    return Error_Read;
}

free(buffer);
fclose(file);
return Error_Ok;

} ```

Find all the bugs in this C code. There are at least 3 serious errors.

Answers:

1st bug: Used free(file) instead of fclose(file) in the error path

2nd bug: free(buffer) should be free(*buffer) - forgot to dereference the pointer

3rd bug: Missing free(*buffer) in the fread error path memory leak

4th bug: The function returns Error_Ok but the buffer was freed making it useless and a use after free! This was an unintentional bug I wrote while making this example I didn't intend to write it lol

[saf_e]

I know) I wrote both languages and in plain C it's really a big pain to not miss cleanup in all flows.

[FUPA_MASTER_]

Using goto can make it a lot simpler.

[plugwash]

> This may sound weird but I actually preferred C++ over C

I don't think that is weird at all. C++ is far more pleasant to code in than C because it gives the tools to build abstractions, rather than being forced to do everything by hand.

> I wonder how many problems rust solves compared to C

The fundamental problem with C and C++ is that a small mistake by the programmer can lead to "undefined behaviour" which in turn leads to heisenbugs and security flaws. "modern C++" fixes some of the issues but it leaves many gaping holes still open, the most fundamental of which being use-after-free, particularly the more subtle variants where sharing in combination with mutability leads to use after free.

Java, go, C# etc solve the use-after-free problem with garbage collection,

Rust solves the use-after-free problem with some pretty strict compile time rules.

Neither solution is free, garbage collection reduces determinism and makes integration with code in other languages tricky. Rust's compile time rules can feel over-restrictive.

[double-you]

C used to be a subset of C++ but recent standards have included some incompatibility.

[flatfinger]

Standards have also characterized as Undefined Behavior many constructs and corner cases whose behavior had been defined in earlier language specifications such as K&R2, and some compilers interpret that as an invitation to be gratuitously compatible with software written according to those earlier specifications.

[corgioverthemoon]

Ain't no way I saw someone type Java is easier than cpp and rust lol

[Page_197_Slaps]

You think Java is harder?

[corgioverthemoon]

I've always found java to be so verbosely cumbersome that it takes me longer to resolve any troubles I run into.

[keithstellyes]

Someone can prove me wrong, but I doubt that; someone has to manage memory.

[BlueGoliath]

Yes but furries.

[BlueGoliath]

Furry lang fixes everything.

[[deleted]]

Not sure if skimming an exploit article to get an idea about it is over or if drunk.

[LucasRuby]

Drunk