4 ms·

A kernel stack use-after-free: Exploiting Nvidia's GPU Linux drivers

mustache_kimono 1y ago
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?
- zetanor 1y ago
  > Why not 4 years? Microsoft might hold a patent on this.
- themafia 1y ago
  > Richest corporation in the world At least until the SEC starts punishing revenue inflation through self-dealing.
  - FridgeSeal 1y ago
    I live for the day.
    - willis936 1y ago
      Immortality hack.
  - pjc50 1y ago
    It worked for Enron, why wouldn't it work for Nvidia? .. ah.
deleted 1y ago
[deleted]
lenerdenator 1y ago
> 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.
- CursedSilicon 1y ago
  To parody the evergreen The Onion headline "No way to prevent this" says proprietary codebases where this always happens
  - tialaramex 1y ago
    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.
    - jibal 1y ago
      Zig pointers are non-null. Optionally null pointers must be explicitly unwrapped.
pinaraf 1y ago
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...
SchwKatze 1y ago
Rust would have prevented that
- tombert 1y ago
  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 .
  - fulafel 1y ago
    Dropping everything is not necessary when porting to Rust, it can be done incrementally and starting with high-risk interfaces.
    - pjmlp 1y ago
      Which is what Microsoft and Google have been doing.

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?

zetanor 1y ago
> Why not 4 years? Microsoft might hold a patent on this.
themafia 1y ago
> Richest corporation in the world At least until the SEC starts punishing revenue inflation through self-dealing.
- FridgeSeal 1y ago
  I live for the day.
  - willis936 1y ago
    Immortality hack.
- pjc50 1y ago
  It worked for Enron, why wouldn't it work for Nvidia? .. ah.

deleted 1y ago

[deleted]

lenerdenator 1y ago

> 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.

CursedSilicon 1y ago
To parody the evergreen The Onion headline "No way to prevent this" says proprietary codebases where this always happens
- tialaramex 1y ago
  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.
  - jibal 1y ago
    Zig pointers are non-null. Optionally null pointers must be explicitly unwrapped.

pinaraf 1y ago

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...

SchwKatze 1y ago

Rust would have prevented that

tombert 1y ago
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 .
- fulafel 1y ago
  Dropping everything is not necessary when porting to Rust, it can be done incrementally and starting with high-risk interfaces.
  - pjmlp 1y ago
    Which is what Microsoft and Google have been doing.