NVIDIA today put out an official Security Bulletin, noting multiple flaws found in their Windows and Linux drivers. The good news is that drivers are already out that fix the problems, which I'll detail below.
Here's all those that affect Linux, brace yourself, there's quite a few of them:
CVE‑2022‑34670 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an unprivileged regular user can cause truncation errors when casting a primitive to a primitive of smaller size causes data to be lost in the conversion, which may lead to denial of service or information disclosure.
CVE‑2022‑42263 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an Integer overflow may lead to denial of service or information disclosure.
CVE‑2022‑34676 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an out-of-bounds read may lead to denial of service, information disclosure, or data tampering.
CVE‑2022‑42264 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer, where an unprivileged regular user can cause the use of an out-of-range pointer offset, which may lead to data tampering, data loss, information disclosure, or denial of service.
CVE‑2022‑34674 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where a helper function maps more physical pages than were requested, which may lead to undefined behavior or an information leak.
CVE‑2022‑34678 - NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where an unprivileged user can cause a null-pointer dereference, which may lead to denial of service.
CVE‑2022‑34679 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an unhandled return value can lead to a null-pointer dereference, which may lead to denial of service.
CVE‑2022‑34680 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an integer truncation can lead to an out-of-bounds read, which may lead to denial of service.
CVE‑2022‑34677 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an unprivileged regular user can cause an integer to be truncated, which may lead to denial of service or data tampering.
CVE‑2022‑34682 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer, where an unprivileged regular user can cause a null-pointer dereference, which may lead to denial of service.
CVE‑2022‑42257 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to information disclosure, data tampering or denial of service.
CVE‑2022‑42265 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to information disclosure or data tampering.
CVE‑2022‑34684 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an off-by-one error may lead to data tampering or information disclosure.
CVE‑2022‑42254 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an out-of-bounds array access may lead to denial of service, data tampering, or information disclosure.
CVE‑2022‑42258 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to denial of service, data tampering, or information disclosure.
CVE‑2022‑42255 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an out-of-bounds array access may lead to denial of service, information disclosure, or data tampering.
CVE‑2022‑42256 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow in index validation may lead to denial of service, information disclosure, or data tampering.
CVE‑2022‑34673 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an out-of-bounds array access may lead to denial of service, information disclosure, or data tampering.
CVE‑2022‑42259 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to denial of service.
There's also a few for NVIDIA VGPU and they affect Tesla too. There's also some that only affect Windows, this isn't a Linux-specific thing but a lot of them are just in their Linux drivers.
As mentioned, the good news is that drivers are already out that solve them. For GeForce users you want minimum driver versions 525.60.11, 515.86.01, 510.108.03, 470.161.03 or 390.157. For RTX, Quadro or NVS you want a minimum driver version of 525.60.11, 515.86.01, 510.108.03, 470.161.03 or 390.157. To put it very simply, if you're not using the very latest NVIDIA drivers in whatever series — update now, all previous versions are vulnerable to the drivers released on November 22nd.
Going by the bulletin page, the issues were public on November 28 but they've seemingly only just actually put out the security bulletin email.
Last edited by fireplace on 2 December 2022 at 7:03 pm UTC
This is all old stuff. NVidia (and most companies in general) publish these reports long after everything has been privately patched. Your software update may look like any other, but there is a good chance it has security fixes. That's why Torvalds doesn't like when people treat security fixes and bug fixes differently. They're all equally important :)I'm afraid it's not all old stuff. In this case previous drivers were compromised, as their bulletin points out you need all the latest drivers in each series, as all previous are vulnerable and the fixed drivers were only released on November 22nd so many people will be out of date.
Yikes.
Security issues are hardly uncommon for stuff like this, Linux users just tend to pay more attention. Kudos for Liam mentioning driver versions, not sure if NVIDIA did too or not. Usually stuff like this is when I have to explain to people what backports are and why their systems are okay.
This is all old stuff. NVidia (and most companies in general) publish these reports long after everything has been privately patched. Your software update may look like any other, but there is a good chance it has security fixes. That's why Torvalds doesn't like when people treat security fixes and bug fixes differently. They're all equally important :)I'm afraid it's not all old stuff. In this case previous drivers were compromised, as their bulletin points out you need all the latest drivers in each series, as all previous are vulnerable and the fixed drivers were only released on November 22nd so many people will be out of date.
The standard "Make sure to keep X up to date" has nothing to do whether any previous version was vulnerable. The CVEs are reported at a much later date by then. Updates will keep coming and new exploits will arise. But all of that doesn't matter. You should keep your software up to date regardless of whether it's a "security fix" or not. Bugs are bugs.
Last edited by fireplace on 2 December 2022 at 7:19 pm UTC
I really don't know what you're trying to get at. The security bulletin is clear about all prior versions to those listed in the article released on November 22nd as being vulnerable.This is all old stuff. NVidia (and most companies in general) publish these reports long after everything has been privately patched. Your software update may look like any other, but there is a good chance it has security fixes. That's why Torvalds doesn't like when people treat security fixes and bug fixes differently. They're all equally important :)I'm afraid it's not all old stuff. In this case previous drivers were compromised, as their bulletin points out you need all the latest drivers in each series, as all previous are vulnerable and the fixed drivers were only released on November 22nd so many people will be out of date.
The standard "Make sure to keep X up to date" has nothing to do whether any previous version was vulnerable. The CVEs are reported at a much later date by then. Updates will keep coming and new exploits will arise. But all of that doesn't matter. You should keep your software up to date regardless of whether it's a "security fix" or not. Bugs are bugs.
I really don't know what you're trying to get at. The security bulletin is clear about all prior versions to those listed in the article released on November 22nd as being vulnerable.This is all old stuff. NVidia (and most companies in general) publish these reports long after everything has been privately patched. Your software update may look like any other, but there is a good chance it has security fixes. That's why Torvalds doesn't like when people treat security fixes and bug fixes differently. They're all equally important :)I'm afraid it's not all old stuff. In this case previous drivers were compromised, as their bulletin points out you need all the latest drivers in each series, as all previous are vulnerable and the fixed drivers were only released on November 22nd so many people will be out of date.
The standard "Make sure to keep X up to date" has nothing to do whether any previous version was vulnerable. The CVEs are reported at a much later date by then. Updates will keep coming and new exploits will arise. But all of that doesn't matter. You should keep your software up to date regardless of whether it's a "security fix" or not. Bugs are bugs.
What I'm trying to say is that all updates are of equal importance. This one isn't somehow special as nvidia probably addressed those privately even if it says that this latest one is the one with all the fixes.
Last edited by fireplace on 2 December 2022 at 7:29 pm UTC
For less technically competent people, like me, how likely are these vulnerabilities to be exploited?
I know there is some degree of difference in how realistic these can be, but nevertheless, I totally agree it's important to update.
Last edited by Terrace on 2 December 2022 at 9:06 pm UTC
The Pop_os guys update the Nvidia drivers very slowly, whats the best way to manually update one time to a version that has these fixes and then let Pop_os go back to updating once they surpass this version?
For the record, Nvidia 525.60.11 is already available on Pop_OS! It just doesn't show in the Pop!_Shop, but you'll find it in the terminal.
sudo apt install nvidia-driver-525
Should do the trick.
Last edited by Mohandevir on 2 December 2022 at 10:17 pm UTC
For the record, Nvidia 525.60.11 is already available on Pop_OS! It just doesn't show in the Pop!_Shop, but you'll find it in the terminal.
sudo apt install nvidia-driver-525
Should do the trick.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package nvidia-driver-525
Is what I end up i'm afraid, not sure how or why, i'm still very uninformed about Linux, just quietly thanking god to be away from the last few hundred patches of Windows 10 for the last few months.
Edit for Sat 3rd Dec 11:33am GMT: Looks like i needed "sudo apt update" then 525.60.11 was found, huzzah! Thank you for the help!
Last edited by Terrace on 3 December 2022 at 11:34 am UTC
Not sure what you're getting at. The yikes is for the massive amount of security holes fixed in one go. That's not common and frankly a bit concerning. Usually stuff like this is when I have to explain to people what CVE's are and why their systems are always vulnerable to some degree.Yikes.Security issues are hardly uncommon for stuff like this, Linux users just tend to pay more attention.
Don't worry about these vulnerabilities too much, if they are exploited on your system, it means that attacker has already penetrated your firewall, logged in, uploaded malware and executed it, or you installed and malware and running it. This is just the icing of security cake.
I think Pop_os comes with something called ufw as a firewall but it's off by default, and i havent looked into turning it on. I also kind of wanted to know how to be on the latest Nvidia drivers too for a gaming reason, something about the latest version being able to use the shaders shipped with the game instead of needing to rebuild them, I'm not completely sure
Don't worry about these vulnerabilities too much, if they are exploited on your system, it means that attacker has already penetrated your firewall, logged in, uploaded malware and executed it, or you installed and malware and running it. This is just the icing of security cake.
I think Pop_os comes with something called ufw as a firewall but it's off by default, and i havent looked into turning it on. I also kind of wanted to know how to be on the latest Nvidia drivers too for a gaming reason, something about the latest version being able to use the shaders shipped with the game instead of needing to rebuild them, I'm not completely sure
Huh? Having a firewall turned off these days on any machine would be very irresponsible. I strongly advise in setting it at least to the default settings of your distro.
That said, I really cannot imagine that Pop has it turned off by default.
Huh? Having a firewall turned off these days on any machine would be very irresponsible. I strongly advise in setting it at least to the default settings of your distro.
That said, I really cannot imagine that Pop has it turned off by default.
It seems to be true, google results for "Pop_os firewall"
Pop!_OS' lack of Firewall by default : r/pop_os - Reddit 1 Nov 2019
Pop!_OS' lack of Firewall by default (since 2 years, and still no change) 7 Sept 2021
7 things to do after installing Pop!_OS - AddictiveTips 28 Jan 2022
Issue/Bug Description: Pop!_OS comes with the ufw firewall installed, but inactive. There is no GUI application to manage the firewal; - Github - 15 Mar 2020
15 Things You MUST DO After Installing Pop!_OS 20.04 - Youtube 14 May 2021
20 Things to do After Installing Pop!_OS 22.04 averagelinuxuser.com 10 Jul 2022
Pop really has it turned off by default, and is the default setting of the distro, it's not me honest!
Last edited by Terrace on 3 December 2022 at 5:48 pm UTC
Pop really has it turned off by default, and is the default setting of the distro, it's not me honest!
No worries, I'm not doubting your honesty :)
Reading a bit on the subject, Ubuntu seems to do the same, ufw is installed, but not active because there are no open ports by default. So apparently I'm slightly out-of-date on this subject, so apologize for my strong wording.
That said, Fedora e.g. has firewalld activated by default so it's not that black and white.
Last edited by jens on 3 December 2022 at 6:52 pm UTC
It's one of those "per system" subjects.Pop really has it turned off by default, and is the default setting of the distro, it's not me honest!
No worries, I'm not doubting your honesty :)
Reading a bit on the subject, Ubuntu seems to do the same, ufw is installed, but not active because there are no open ports by default. So apparently I'm slightly out-of-date on this subject, so apologize for my strong wording.
That said, Fedora e.g. has firewalld activated by default so it's not that black and white.
In a home setup it may not be strictly necessary because a home user may have no services running, for example no sshd, no cups etc that listen on a public interface - thus said services that are not running cannot be exploited.
But without the firewall you do run a minor risk, that is third party software you install as a user; what happens if you install something and you are not aware that it opens a listening port? In this instance a firewall would protect you.
Typically home computers sit behind a firewall already, in the form of your routers built-in firewall. Thus protected from the outside world unless you forward a port on that device.
Firewalls are also useful if for example you want to enable ssh access while connected to your home WiFi but disable it on other WiFi networks.
They're also useful in the case of server systems where said systems do not sit behind any other firewall where services may get activated, not configured correctly, and forgotten.
For both, you may wish to only enable access to a port from a limited range of ip addresses, or perhaps through a specific interface etc. Again, firewall is preferred here.
(Yes, you can bind a service to a particular IP address of using a firewall, or even have do both. But I'm talking about firewalls here)
PS: Apologies if this doesn't make sense! In a bit of a rush
Last edited by jens on 4 December 2022 at 6:57 am UTC
Yeah, my personal preference is still to always enable the firewall (also in a home setup) and I still recommend to do so, but I guess it is no longer a sin to not do so.There's nothing wrong with that
In fact, I do the same. I was merely explaining why some may or may not use a firewall. My biggest complaint is that ssh is activated by default on new installs with password authentication and some distros then open up port 22. It's basically asking for trouble.
(If there's one thing everyone absolutely should do is disable ssh password authentication and if using ssh, switch to key based authentication . If not using it, disable the service.)
Last edited by BlackBloodRum on 4 December 2022 at 7:52 am UTC
See more from me