Here's something we missed with the latest NVIDIA driver updates - turns out that NVIDIA had multiple security issues that they put out in a recent security bulletin. Multiple issues affect both Windows and Linux, across multiple versions of the official NVIDIA proprietary driver.
The ones that affect the Linux desktop are:
- CVE‑2021‑1052: "NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape or IOCTL in which user-mode clients can access legacy privileged APIs, which may lead to denial of service, escalation of privileges, and information disclosure."
- CVE‑2021‑1053: "NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape or IOCTL in which improper validation of a user pointer may lead to denial of service."
- CVE‑2021‑1056: "NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko) in which it does not completely honor operating system file system permissions to provide GPU device-level isolation, which may lead to denial of service or information disclosure."
There's also some vGPU security issues too, which also affect Linux but they're not regular desktop stuff.
If you want to make sure you're totally safe you should update to the latest driver in the series you're using. Going by the information on the NVIDIA security page you should be good on (or better) 460.32.03 which is the latest "Production Branch" driver, 450.102.04 and 390.141 being the latest Legacy driver.
You can look out for future security info here from NVIDIA.
Quoting: SchattenspiegelQuoting: ShaddycatDoesn't work on my machine. I get stuck at a super low resolution and 76 Hz. Using a GTX 1080 on Mint. Anyone else have a similar issue?Did you manually upgrade from the nvidia page or did you use the driver tool provided by Linux Mint in combination with the ppa?
I'll just stick to 450 for now I think.
I updated with the driver tool provided by Mint.
Quoting: TheRiddickI've found updating GPU drivers and MESA to be much easier under Arch based Linux, AUR is a godsend also! The whole PPA Ubuntu random packages method was rather clunky to deal with!A Mesa update is just as simple to install as any other update, isn't it?
Are the packages in AUR less "random" than ones in a PPA?
Quoting: ShaddycatI updated with the driver tool provided by Mint.Sorry, no clue then.
Quoting: tuubiWell mesa being a library that a lot of things depend upon, and PPAs basically being a wild west and not officially supported by Ubuntu...Quoting: TheRiddickI've found updating GPU drivers and MESA to be much easier under Arch based Linux, AUR is a godsend also! The whole PPA Ubuntu random packages method was rather clunky to deal with!A Mesa update is just as simple to install as any other update, isn't it?
Are the packages in AUR less "random" than ones in a PPA?
And with Arch they are core libraries and so things that need to be rebuilt on those are rebuilt at the same time the libraries are. It is one of the 'pros' of running a Rolling release. If you are someone who always needs bleeding edge drivers / libraries, Arch is fantastic at keeping things up to date. If I ran AMD stuff, I would probably just stick to Arch.
Snaps were created to try and stop the many PPAs from being needed.
Quoting: slaapliedjeA wild west just like AUR then. I use a grand total of three PPAs on my gaming/entertainment box currently BTW, one owned and updated by a Valve employee, and the other two by the teams who develop the software I download from those PPAs. Do you always check who wrote the pkgbuilds you download from AUR?Quoting: tuubiWell mesa being a library that a lot of things depend upon, and PPAs basically being a wild west and not officially supported by Ubuntu...Quoting: TheRiddickI've found updating GPU drivers and MESA to be much easier under Arch based Linux, AUR is a godsend also! The whole PPA Ubuntu random packages method was rather clunky to deal with!A Mesa update is just as simple to install as any other update, isn't it?
Are the packages in AUR less "random" than ones in a PPA?
QuoteAnd with Arch they are core libraries and so things that need to be rebuilt on those are rebuilt at the same time the libraries are. It is one of the 'pros' of running a Rolling release.Having to build a bunch of stuff yourself is a pro?
I was a Gentoo user for a couple of years so I see what you're trying to say, but for most users that really isn't a pro.
QuoteIf you are someone who always needs bleeding edge drivers / libraries, Arch is fantastic at keeping things up to date. If I ran AMD stuff, I would probably just stick to Arch.I don't see why I would, and I actually run AMD stuff. If you mainly use your computer for gaming, you're best off running something close to what game developers test against, with just your graphics drivers updated to the latest and greatest.
There are good reasons to prefer a rolling distro but gaming isn't one. If you just want to play your games, you don't really care about most libraries being bleeding edge as much as you care about having a supported system. That's why we have steam runtimes and whatnot.
QuoteSnaps were created to try and stop the many PPAs from being needed.I doubt that was even in the top five reasons.
I guess this discussion is a bit off topic here.
Quoting: PhiladelphusSo, obviously security vulnerabilities are bad and I'm going to update ASAP, but just how bad are these, really? Do I have to worry about some carefully crafted bad GIF on a shady website making my GPU run arbitrary code as root, or what?I learned recently of a new fetish about people who get aroused by rescuing people from quicksand. They are apparently called Sinkers... so your computer will get filled with sinker porn!
Quoting: PhiladelphusSo, obviously security vulnerabilities are bad and I'm going to update ASAP, but just how bad are these, really? Do I have to worry about some carefully crafted bad GIF on a shady website making my GPU run arbitrary code as root, or what?
Nah, the rendering is done by the browser and through the compositor. You'd likely have to run a rogue application or a very badly designed rendering application that'd run arbitrary code. I'll try to go get some more information.
Fun fact: simple stuff taken for granted like jpg libraries had countless vulns and exploit in older versions, and carefully crafted image files could have been detrimental.
https://security.stackexchange.com/questions/97856/can-simply-decompressing-a-jpeg-image-trigger-an-exploit
Not to even mention ImageTragick.
Quoting: aokamiNah, the rendering is done by the browser and through the compositor. You'd likely have to run a rogue application or a very badly designed rendering application that'd run arbitrary code. I'll try to go get some more information.Interesting, thanks. While my question was a bit hyperbolic, I'm glad to learn about things like this.
Fun fact: simple stuff taken for granted like jpg libraries had countless vulns and exploit in older versions, and carefully crafted image files could have been detrimental.
https://security.stackexchange.com/questions/97856/can-simply-decompressing-a-jpeg-image-trigger-an-exploit
Not to even mention ImageTragick.
Quoting: PhiladelphusI remember first reading about that and couldn't help but wonder how one would not notice a corrupted image with a payload, but ehen looking into it, sure enough it was possible simply because of the way jpg worked. Crazy.Quoting: aokamiNah, the rendering is done by the browser and through the compositor. You'd likely have to run a rogue application or a very badly designed rendering application that'd run arbitrary code. I'll try to go get some more information.Interesting, thanks. While my question was a bit hyperbolic, I'm glad to learn about things like this.
Fun fact: simple stuff taken for granted like jpg libraries had countless vulns and exploit in older versions, and carefully crafted image files could have been detrimental.
https://security.stackexchange.com/questions/97856/can-simply-decompressing-a-jpeg-image-trigger-an-exploit
Not to even mention ImageTragick.
See more from me