A Kernel Stack Use-After-Free: Exploiting Nvidia's GPU Linux Drivers
Posted3 months agoActive3 months ago
blog.quarkslab.comTechstory
controversialmixed
Debate
80/100
Linux KernelNvidia GPU DriversVulnerability Exploitation
Key topics
Linux Kernel
Nvidia GPU Drivers
Vulnerability Exploitation
A security researcher disclosed a kernel stack use-after-free vulnerability in Nvidia's GPU Linux drivers, sparking debate over disclosure timelines and the implications of the bug.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
1h
Peak period
9
6-12h
Avg / period
3.4
Comment distribution31 data points
Loading chart...
Based on 31 loaded comments
Key moments
- 01Story posted
Oct 15, 2025 at 9:52 AM EDT
3 months ago
Step 01 - 02First comment
Oct 15, 2025 at 11:09 AM EDT
1h after posting
Step 02 - 03Peak activity
9 comments in 6-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 18, 2025 at 5:00 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45592585Type: storyLast synced: 11/20/2025, 2:00:08 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> 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?
At least until the SEC starts punishing revenue inflation through self-dealing.
Microsoft might hold a patent on this.
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" says proprietary codebases where this always happens
"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.
What is my_ptr->member but unwrapping an optionally null pointer.
It’s the whole make it easy to write good code—not impossible to write incorrect code philosophy of the language.
> 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:Followed by never touching the variable ever again.
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.
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.
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.
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!
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.
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 .
10 more comments available on Hacker News