> 2025-08-11 NVIDIA reiterated the request to postpone disclosure until mid-January 2026.
> 2025-08-12 Quarkslab replied that the bugs were first reported in June 18th and mid-January was well past the standard 90 day normally agreed for coordinated disclosure and that we did not see a rationale for postponing publication by, at a minimum, 3 months. Therefore Quarkslab continued with the publication deadline set to September 23rd 2025 and offered to extend the deadline an additional 30 days provided NVIDIA gave us some insights about the full scope of affected products and if the fixes are to be released as a stand alone security fix, as opposed to rolled into a version bump that includes other code changes.
Richest corporation in the world needs 7 months to remedy? Why not 4 years?
> Back in 2022, NVIDIA started distributing the Linux Open GPU Kernel Modules. Since 2024, using these modules is officially "the right move" for both consumer and server hardware. The driver provides multiple kernel modules, the bugs being found in nvidia.ko and nvidia-uvm.ko. They expose ioctls on device files, most of them being accessible to unprivileged users. These ioctls are meant to be used by NVIDIA's proprietary userland binaries and libraries. However, using the header files provided in the kernel modules repository as a basis, it's possible to make direct ioctl calls.
If only there were some way to release the source code for your userland programs so that the computing public could look at the code, then offer a fix for a bug such as this.
Unfortunately, so far as I'm aware, there is no way to do this and having a few people who are working against what has to be a large number of deadlines look at extremely low-level code for very sophisticated software is the only way forward for these things.
"No way to prevent this" say programmers of only languages where this regularly happens.
This only happens if you have the worst version of Tony's Billion Dollar Mistake. So C, C++, Zig, Odin and so on but not Rust.
It's a use-after-free, a category of mistake that's impossible in true GC languages, and also impossible in safe Rust. We have known, for many years, how to not have this problem, but some people who ought to know better insist they can't stop it, exactly like America's gun violence.
> This only happens if you have the worst version of Tony's Billion Dollar Mistake. So C, C++, ==> Zig <==, Odin and so on but not Rust.
The billion dollar mistake is making NULL a valid pointer value, not use after free--which has nothing to do with null pointers and which I didn't comment on, as the comment I responded to only mentioned Zig in regard to the billion dollar mistake. The billion dollar mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test.
I agree that's an error on my part - Zig does not actually have the billion dollar mistake, although I don't think the approach taken is very good it's clearly not just the billion dollar mistake and so I was wrong to say that.
> although I don't think the approach taken is very good
The approach taken is the same as in virtually every other language that has avoided the billion dollar mistake -- null is not a valid pointer value, and instead there's an additional union type (called Optional, Maybe, etc.) that can hold Some(pointer) or None. Zig, like some other languages, extends this union beyond pointers to other types.
It’s semantics. Zig can still have dangling references/uaf. You can do something like ‘var foo: *Bar = @intToPtr(0x00)’ but in order to “properly” use the zero address to represent state you have to use ‘var foo: ?*Bar = null’ which is a different type than ‘*Bar’ that the compiler will force you to check before accessing.
It’s the whole make it easy to write good code—not impossible to write incorrect code philosophy of the language.
Judging from the article, Zig would have prevented the CVE.
> This includes memory allocations of type NV01_MEMORY_DEVICELESS which are not associated with any device and therefore have the pGpu field of their corresponding MEMORY_DESCRIPTOR structure set to null
This does look like the type of null deref that Zig does prevent.
Looking at the second issue in the chain, I believe standard Zig would have prevented that as well.
The C code had an error that caused the call to free to be skipped:
threadStateInit(&threadState, THREAD_STATE_FLAGS_NONE);
status = rmapiMapWithSecInfo(/*…*/); // null deref here
threadStateFree(&threadState, THREAD_STATE_FLAGS_NONE);
Zig’s use of ‘defer’ would ensure that free is called even if an error occurred:
threadStateInit(&threadState, THREAD_STATE_FLAGS_NONE);
defer threadStateFree(&threadState, THREAD_STATE_FLAGS_NONE);
status = try rmapiMapWithSecInfo(/*…*/); // null deref here
Nothing can prevent a sufficiently belligerent programmer from writing bad code. Not even Rust—which I assume you’re advocating for without reading the greater context of this thread.
No, the solutions I spoke about were language features that make it trivial to avoid or impossible to make the mistakes.
If your bar for mistakes is “what if you forget to add literally the next line of code in the incredibly common pattern”, I don’t really care to have a discussion about programming languages anymore.
You can forget to increment a loop and have your program not terminate so why don’t you program with language of exclusively primitive recursive functions?
You won't get anywhere with people who just like to argue.
Note that the mention of Zig that I responded to was in reference to Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type, not free after use, which is a quite different issue. As I noted, the mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test.
I do think it's a bit too easy to forget a deferred free, although it's possible for tools to detect them. Unfortunately Andrew Kelley is prone to being extremely opinionated about language design (GingerBill is another of that sort) and so macros are forever banned from Zig, but macros are the only mechanism for encapsulating a scoped feature like defer.
> You won't get anywhere with people who just like to argue.
Yeah not really sure why I bother. I think I just get bothered that Rust gets touted everywhere as a silver bullet.
> Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type
It’s funny how we got stuck with his biggest mistake for decades and his (probably not entirely his) algebraic types / tagged unions have just started to get first class support now.
You were correct about the lack of billion dollar mistake in Zig, once I'd decided to list some "C replacement" languages not just C and C++ I should have either checked they all make exactly this mistake (Odin does, Zig does not) or removed that part of my comment.
However actually in practice for this nVidia bug Zig's "defer" is just irrelevant, which is why nVidia's "fix" doesn't attempt the most similar C equivalent strategy and instead now performs a heap allocation (and thus free) on the happy path.
There's a kernel Oops, likely in someone else's code. When that happens our stack goes away. In Rust they can (I don't happen to know if they do in Rust for Linux but it is commonly used in some types of application) recover from disasters and unwind the stack before it's gone, such as removing the threadState from that global state. In Zig that's prohibited by the language design, all panics are fatal.
A kernel oops isn’t a panic at least however zig or rust defines a panic. So zig saying things about panics don’t apply here.
Rust fails here the same exact way if drop semantics aren’t upheld (they aren’t afaik). Also Rust’s soundness goes immediately out the window if UB happens in unsafe code. So immediately when a kernel Oops happens safety is moot point.
I’m not sure if Zig has a clean way to kill a thread, unwind the stack, and run deferred code. Zig is a pre-1.0 language after all so it’s allowed to be missing features.
> What is my_ptr->member but unwrapping an optionally null pointer.
It's a dereference of a pointer that might be null and thereby yield undefined behavior; there's no required unwrapping under an explicit test for null, as is required by Zig. In Zig, my_ptr cannot be null in my_ptr.member -- null is not a valid pointer value. If my_ptr is an optionally null pointer then the pointer value must be unwrapped by first checking whether it is null ... the dereference can only occur in the test branch where the pointer isn't null.
Note that the mention of Zig that I responded to was in reference to Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type. As I noted, the mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test.
If you had no idea what I was referring to, you might have asked. Rather, you asked a rhetorical question with no question mark, implying the falsehood that my_ptr->member is "unwrapping an optionally null pointer" when it's nothing of the sort.
> If only there were some way to release the source code for your userland programs so that the computing public could look at the code, then offer a fix for a bug such as this.
These bugs are in the already open sourced kernel modules, the userland components are largely irrelevant as long as an attacker can just do invoke the affected ioctl directly.
Counterargument: security by obscurity does work. The common strawman is that it doesn't, but that's when it's the only defence.
See Spectre and Meltdown - if it was easy to exploit then we would all be pwned unpatched just by running the Windows installer - just like how Windows XP machines used to do that back in the day....
If your exploit requires lots of disassembling, decrypting random ad-hoc custom crypto, and even finding what you're looking for in some random 100MB .dll, that just isn't very likely to be found except by the nationstate guys. The signal-to-noise ratio is a wonderful thing. It's much easier to hide something amongst very mundane things (most secrets are boring) than to heavily guard something and advertise "SECRETS ARE HERE". There's quite a few examples of this in various programs and web services, you obviously don't know because you didn't find it!
Heh, good point, but it isn't really true when you invert it :) If you randomly search for stuff, you're very unlikely to find anything, only if you know what you are searching for, only then you find something...
You're not wrong but I think it's sort of irrelevant. Rust is cool but from my understanding, graphics card drivers are almost an entire OS in itself. I don't think Nvidia is writing a new driver for each GPU, I think they're using a core driver codebase and making relevant modifications for each card.
My point is that I suspect that the Nvidia driver is a decades-long project, and dropping everything and rewriting in Rust isn't really realistic .
Check out the disclosure timeline.
> 2025-08-11 NVIDIA reiterated the request to postpone disclosure until mid-January 2026.
> 2025-08-12 Quarkslab replied that the bugs were first reported in June 18th and mid-January was well past the standard 90 day normally agreed for coordinated disclosure and that we did not see a rationale for postponing publication by, at a minimum, 3 months. Therefore Quarkslab continued with the publication deadline set to September 23rd 2025 and offered to extend the deadline an additional 30 days provided NVIDIA gave us some insights about the full scope of affected products and if the fixes are to be released as a stand alone security fix, as opposed to rolled into a version bump that includes other code changes.
Richest corporation in the world needs 7 months to remedy? Why not 4 years?
> Richest corporation in the world
At least until the SEC starts punishing revenue inflation through self-dealing.
I live for the day.
Immortality hack.
It worked for Enron, why wouldn't it work for Nvidia? .. ah.
> Why not 4 years?
Microsoft might hold a patent on this.
And the latest driver available for Jetson Thor doesn't have the fixes for these two CVEs because they decided to fork their own driver...
> Back in 2022, NVIDIA started distributing the Linux Open GPU Kernel Modules. Since 2024, using these modules is officially "the right move" for both consumer and server hardware. The driver provides multiple kernel modules, the bugs being found in nvidia.ko and nvidia-uvm.ko. They expose ioctls on device files, most of them being accessible to unprivileged users. These ioctls are meant to be used by NVIDIA's proprietary userland binaries and libraries. However, using the header files provided in the kernel modules repository as a basis, it's possible to make direct ioctl calls.
If only there were some way to release the source code for your userland programs so that the computing public could look at the code, then offer a fix for a bug such as this.
Unfortunately, so far as I'm aware, there is no way to do this and having a few people who are working against what has to be a large number of deadlines look at extremely low-level code for very sophisticated software is the only way forward for these things.
To parody the evergreen The Onion headline
"No way to prevent this" says proprietary codebases where this always happens
I've always thought the correct analogy was:
"No way to prevent this" say programmers of only languages where this regularly happens.
This only happens if you have the worst version of Tony's Billion Dollar Mistake. So C, C++, Zig, Odin and so on but not Rust.
It's a use-after-free, a category of mistake that's impossible in true GC languages, and also impossible in safe Rust. We have known, for many years, how to not have this problem, but some people who ought to know better insist they can't stop it, exactly like America's gun violence.
Zig pointers are non-null. Optionally null pointers must be explicitly unwrapped.
Assuming they are still valid, Zig doesn't prevent use after free.
> This only happens if you have the worst version of Tony's Billion Dollar Mistake. So C, C++, ==> Zig <==, Odin and so on but not Rust.
The billion dollar mistake is making NULL a valid pointer value, not use after free--which has nothing to do with null pointers and which I didn't comment on, as the comment I responded to only mentioned Zig in regard to the billion dollar mistake. The billion dollar mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test.
I agree that's an error on my part - Zig does not actually have the billion dollar mistake, although I don't think the approach taken is very good it's clearly not just the billion dollar mistake and so I was wrong to say that.
> although I don't think the approach taken is very good
The approach taken is the same as in virtually every other language that has avoided the billion dollar mistake -- null is not a valid pointer value, and instead there's an additional union type (called Optional, Maybe, etc.) that can hold Some(pointer) or None. Zig, like some other languages, extends this union beyond pointers to other types.
so... references and pointers?
What is my_ptr->member but unwrapping an optionally null pointer.
It’s semantics. Zig can still have dangling references/uaf. You can do something like ‘var foo: *Bar = @intToPtr(0x00)’ but in order to “properly” use the zero address to represent state you have to use ‘var foo: ?*Bar = null’ which is a different type than ‘*Bar’ that the compiler will force you to check before accessing.
It’s the whole make it easy to write good code—not impossible to write incorrect code philosophy of the language.
Thus it would not prevent a CVE like the one being discussed.
Judging from the article, Zig would have prevented the CVE.
> This includes memory allocations of type NV01_MEMORY_DEVICELESS which are not associated with any device and therefore have the pGpu field of their corresponding MEMORY_DESCRIPTOR structure set to null
This does look like the type of null deref that Zig does prevent.
Looking at the second issue in the chain, I believe standard Zig would have prevented that as well.
The C code had an error that caused the call to free to be skipped:
Zig’s use of ‘defer’ would ensure that free is called even if an error occurred:Assuming the user would not have forgotten to type the line with defer, and correctly as well, like all great coders.
Followed by never touching the variable ever again.
Nothing can prevent a sufficiently belligerent programmer from writing bad code. Not even Rust—which I assume you’re advocating for without reading the greater context of this thread.
We're literally in a thread about the famous Onion recurring story.
"'No Way to Prevent This,' Says Only Nation Where This Regularly Happens"
I literally replied with “A Way to Prevent This”?
"Don't make mistakes" isn't a way to prevent this. We know that doesn't work.
No, the solutions I spoke about were language features that make it trivial to avoid or impossible to make the mistakes.
If your bar for mistakes is “what if you forget to add literally the next line of code in the incredibly common pattern”, I don’t really care to have a discussion about programming languages anymore.
You can forget to increment a loop and have your program not terminate so why don’t you program with language of exclusively primitive recursive functions?
You won't get anywhere with people who just like to argue.
Note that the mention of Zig that I responded to was in reference to Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type, not free after use, which is a quite different issue. As I noted, the mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test.
I do think it's a bit too easy to forget a deferred free, although it's possible for tools to detect them. Unfortunately Andrew Kelley is prone to being extremely opinionated about language design (GingerBill is another of that sort) and so macros are forever banned from Zig, but macros are the only mechanism for encapsulating a scoped feature like defer.
> You won't get anywhere with people who just like to argue.
Yeah not really sure why I bother. I think I just get bothered that Rust gets touted everywhere as a silver bullet.
> Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type
It’s funny how we got stuck with his biggest mistake for decades and his (probably not entirely his) algebraic types / tagged unions have just started to get first class support now.
You were correct about the lack of billion dollar mistake in Zig, once I'd decided to list some "C replacement" languages not just C and C++ I should have either checked they all make exactly this mistake (Odin does, Zig does not) or removed that part of my comment.
However actually in practice for this nVidia bug Zig's "defer" is just irrelevant, which is why nVidia's "fix" doesn't attempt the most similar C equivalent strategy and instead now performs a heap allocation (and thus free) on the happy path.
There's a kernel Oops, likely in someone else's code. When that happens our stack goes away. In Rust they can (I don't happen to know if they do in Rust for Linux but it is commonly used in some types of application) recover from disasters and unwind the stack before it's gone, such as removing the threadState from that global state. In Zig that's prohibited by the language design, all panics are fatal.
What a crap, disingenuous argument.
A kernel oops isn’t a panic at least however zig or rust defines a panic. So zig saying things about panics don’t apply here.
Rust fails here the same exact way if drop semantics aren’t upheld (they aren’t afaik). Also Rust’s soundness goes immediately out the window if UB happens in unsafe code. So immediately when a kernel Oops happens safety is moot point.
I’m not sure if Zig has a clean way to kill a thread, unwind the stack, and run deferred code. Zig is a pre-1.0 language after all so it’s allowed to be missing features.
> I’m not sure if Zig has a clean way to kill a thread, unwind the stack, and run deferred code.
Zig deliberately only has fatal panic. This isn't a "missing feature" it's intentional
> What is my_ptr->member but unwrapping an optionally null pointer.
It's a dereference of a pointer that might be null and thereby yield undefined behavior; there's no required unwrapping under an explicit test for null, as is required by Zig. In Zig, my_ptr cannot be null in my_ptr.member -- null is not a valid pointer value. If my_ptr is an optionally null pointer then the pointer value must be unwrapped by first checking whether it is null ... the dereference can only occur in the test branch where the pointer isn't null.
Note that the mention of Zig that I responded to was in reference to Tony Hoare's "billion dollar mistake", which was making null a valid value of a pointer type. As I noted, the mistake doesn't occur in Zig because null is not a valid value for a pointer, only an optional pointer, which must be unwrapped with an explicit null test.
If you had no idea what I was referring to, you might have asked. Rather, you asked a rhetorical question with no question mark, implying the falsehood that my_ptr->member is "unwrapping an optionally null pointer" when it's nothing of the sort.
> If only there were some way to release the source code for your userland programs so that the computing public could look at the code, then offer a fix for a bug such as this.
These bugs are in the already open sourced kernel modules, the userland components are largely irrelevant as long as an attacker can just do invoke the affected ioctl directly.
Counterargument: security by obscurity does work. The common strawman is that it doesn't, but that's when it's the only defence.
See Spectre and Meltdown - if it was easy to exploit then we would all be pwned unpatched just by running the Windows installer - just like how Windows XP machines used to do that back in the day....
If your exploit requires lots of disassembling, decrypting random ad-hoc custom crypto, and even finding what you're looking for in some random 100MB .dll, that just isn't very likely to be found except by the nationstate guys. The signal-to-noise ratio is a wonderful thing. It's much easier to hide something amongst very mundane things (most secrets are boring) than to heavily guard something and advertise "SECRETS ARE HERE". There's quite a few examples of this in various programs and web services, you obviously don't know because you didn't find it!
I buried gold in your backyard!
Heh, good point, but it isn't really true when you invert it :) If you randomly search for stuff, you're very unlikely to find anything, only if you know what you are searching for, only then you find something...
Rust would have prevented that
You're not wrong but I think it's sort of irrelevant. Rust is cool but from my understanding, graphics card drivers are almost an entire OS in itself. I don't think Nvidia is writing a new driver for each GPU, I think they're using a core driver codebase and making relevant modifications for each card.
My point is that I suspect that the Nvidia driver is a decades-long project, and dropping everything and rewriting in Rust isn't really realistic .
Dropping everything is not necessary when porting to Rust, it can be done incrementally and starting with high-risk interfaces.
Which is what Microsoft and Google have been doing.