CVE‑2023‑25516
NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer, where an unprivileged user can cause an integer overflow, which may lead to information disclosure and denial of service.

CVE‑2023‑25517
NVIDIA vGPU software contains a vulnerability in the Virtual GPU Manager (vGPU plugin), where a guest OS may be able to control resources for which it is not authorized, which may lead to information disclosure and data tampering.

In nonfree release we have

 535.54.03-2.mga9

 530.41.03-3.mga9

 470.182.03-5.mga9

no 525.

CC: (none) => fri

R470 pushed to Cauldron Nonfree Updates Testing with a request for tests on dev@ and qa@ mls.

Will push mga8 updates soon-ish

Version: Cauldron => 8
QA Contact: (none) => security
Component: RPM Packages => Security

Thank you psyca for the report.
Thank you for your prompt response, Thomas.
Assigning the bug to kernel/drivers.

Assignee: bugsquad => kernel

R470, on my workstation, GTX750 GPU

This have been working recently with 470, 525, 530, 535
But I also earlier have had problems like below when shifting driver, so it may be tool problem and not driver that makes it fail per below:


In Plasma desktop, using mcc: enbled nonfree testing,
 selected Nvidia > latest legacy

No visible problem, and i watched CPU working the dkms

From journal:
jun 28 21:45:24 svarten.tribun [RPM][391466]: install x11-driver-video-nvidia470-470.199.02-1.mga9.nonfree.x86_64: success
jun 28 21:45:27 svarten.tribun [RPM][391466]: install nvidia470-doc-html-470.199.02-1.mga9.nonfree.x86_64: success
jun 28 21:45:27 svarten.tribun [RPM][391466]: install dkms-nvidia470-470.199.02-1.mga9.nonfree.x86_64: success
jun 28 21:45:27 svarten.tribun [RPM][391466]: install nvidia470-utils-470.199.02-1.mga9.nonfree.x86_64: success
jun 28 21:45:27 svarten.tribun [RPM][391466]: install x11-driver-video-nvidia470-470.199.02-1.mga9.nonfree.x86_64: success

Reboot to black screen instead of login.
Also plain black text vt at ctrl-altF3 etc.
ctrl-alt-bksps-bksps yeilded no visible response. 
ctrl-alt-del-del -> controlled reboot.

In Grub selected maintenance, root login, telinit3, root login, drakx11 and selected default Geforce 745 series and later, which proceeded normally.
Back at promt, it do not display anything I type but accept commands.
Issued reboot and it reboot perfectly using 535.54.03-2.mga9.

Back in Plasma, launching drakx11 I notice a quirk:
It use to display the used driver, but now it falsely display the legacy driver is in use. (I verify nvidia-settings say 535), so something is broken there.
I have seen this before, but have not yet understand when it works and when not.

$ uname -a
Linux svarten.tribun 6.3.9-desktop-2.mga9 #1 SMP PREEMPT_DYNAMIC Fri Jun 23 07:46:59 UTC 2023 x86_64 GNU/Linux

(In reply to Morgan Leijström from comment #5)
> R470, on my workstation, GTX750 GPU
> 
> This have been working recently with 470, 525, 530, 535
> But I also earlier have had problems like below when shifting driver, so it
> may be tool problem and not driver that makes it fail per below:
> 
> 
> In Plasma desktop, using mcc: enbled nonfree testing,
>  selected Nvidia > latest legacy
> 
> No visible problem, and i watched CPU working the dkms
> 
> From journal:
> jun 28 21:45:24 svarten.tribun [RPM][391466]: install
> x11-driver-video-nvidia470-470.199.02-1.mga9.nonfree.x86_64: success
> jun 28 21:45:27 svarten.tribun [RPM][391466]: install
> nvidia470-doc-html-470.199.02-1.mga9.nonfree.x86_64: success
> jun 28 21:45:27 svarten.tribun [RPM][391466]: install
> dkms-nvidia470-470.199.02-1.mga9.nonfree.x86_64: success
> jun 28 21:45:27 svarten.tribun [RPM][391466]: install
> nvidia470-utils-470.199.02-1.mga9.nonfree.x86_64: success
> jun 28 21:45:27 svarten.tribun [RPM][391466]: install
> x11-driver-video-nvidia470-470.199.02-1.mga9.nonfree.x86_64: success
> 
> Reboot to black screen instead of login.
> Also plain black text vt at ctrl-altF3 etc.

> ctrl-alt-bksps-bksps yeilded no visible response.

which means there was no Xorg running to kill/zap.
 
> ctrl-alt-del-del -> controlled reboot.
> 
> In Grub selected maintenance, root login, telinit3, root login, drakx11 and
> selected default Geforce 745 series and later, which proceeded normally.
> Back at promt, it do not display anything I type but accept commands.
> Issued reboot and it reboot perfectly using 535.54.03-2.mga9.
> 
> Back in Plasma, launching drakx11 I notice a quirk:
> It use to display the used driver, but now it falsely display the legacy
> driver is in use. (I verify nvidia-settings say 535), so something is broken
> there.
> I have seen this before, but have not yet understand when it works and when
> not.

For 470 can you try with:

- boot in init level 3, then start X11 manually with startx. What I noticed is that sometimes sddm starts but the system fails inserting the nvidia modules (seems it doesn't do in time because sddm starts faster). This happens with stock sddm-0.19.0-16.mga9. It works, i.e. doesn't happens, instead with the newer sddm-0.20.0-0.mga9 that I posted here https://download.copr.fedorainfracloud.org/results/ghibo/mageia9-bonus/mageia-cauldron-x86_64/06097855-sddm.

- When there is the black screen, check, if system is still responsive, that:
/proc/cmdline contains 'nokmsmod':

update-alternatives --display gl_conf

shows the pointers to the nvidia470. Also check there aren't nouveau modules floating (lsmod|grep nouveau). In case try also as test to boot (volatile, i.e. no need for adding to /etc/default/grub) adding nouveau.modeset=0.

- If Xorg has ever started /var/log/Xorg.0.log might contains infos about what's wrong. But be sure it's from current run and not from previous (at most cleanup it before running).

CC: (none) => ghibomgx

(In reply to Giuseppe Ghibò from comment #7)
> What I noticed
> is that sometimes sddm starts but the system fails inserting the nvidia
> modules (seems it doesn't do in time because sddm starts faster). This
> happens with stock sddm-0.19.0-16.mga9.

I think you should open a bug on that.

Is there a missing interlock, and we are just lucky that it mostly works?


> It works, i.e. doesn't happens,
> instead with the newer sddm-0.20.0-0.mga9 that I posted here

This system use that sddm.


I will try more another day.

Is this "sometimes" failing enough to make an errata entry?

(In reply to Morgan Leijström from comment #9)
> Is this "sometimes" failing enough to make an errata entry?

No. To weird.
(In reply to Morgan Leijström from comment #8)
> (In reply to Giuseppe Ghibò from comment #7)
> > What I noticed
> > is that sometimes sddm starts but the system fails inserting the nvidia
> > modules (seems it doesn't do in time because sddm starts faster). This
> > happens with stock sddm-0.19.0-16.mga9.
> 
> I think you should open a bug on that.
> 
> Is there a missing interlock, and we are just lucky that it mostly works?
> 
> 
> > It works, i.e. doesn't happens,
> > instead with the newer sddm-0.20.0-0.mga9 that I posted here
> 
> This system use that sddm.
> 
> 
> I will try more another day.

(In reply to Morgan Leijström from comment #8)
> (In reply to Giuseppe Ghibò from comment #7)
> > What I noticed
> > is that sometimes sddm starts but the system fails inserting the nvidia
> > modules (seems it doesn't do in time because sddm starts faster). This
> > happens with stock sddm-0.19.0-16.mga9.
> 
> I think you should open a bug on that.
> 
> Is there a missing interlock, and we are just lucky that it mostly works?
> 
> 
> > It works, i.e. doesn't happens,
> > instead with the newer sddm-0.20.0-0.mga9 that I posted here
> 
> This system use that sddm.
> 
> 
> I will try more another day.

(In reply to Morgan Leijström from comment #8)

> (In reply to Giuseppe Ghibò from comment #7)
> > What I noticed
> > is that sometimes sddm starts but the system fails inserting the nvidia
> > modules (seems it doesn't do in time because sddm starts faster). This
> > happens with stock sddm-0.19.0-16.mga9.
> 
> I think you should open a bug on that.
> 
> Is there a missing interlock, and we are just lucky that it mostly works?
> 
> 
> > It works, i.e. doesn't happens,
> > instead with the newer sddm-0.20.0-0.mga9 that I posted here
> 
> This system use that sddm.

If already fails with sddm-0.20.0, then it's something other. I guess startx won't have effect too. Just to know if you go back to nvidia470-470.182.03-5.mga9 do you get the same problems?

(In reply to Morgan Leijström from comment #9)

> Is this "sometimes" failing enough to make an errata entry?

No, too complex to handle for an errata, happens on a system but not on another (startx works anyway), and with custom sddm-0.20.0 it sanitize all and the switch between "any" driver in drakx11 just works all the times with just doing "selecting" driver, install driver, click "ok", reboot.

(In reply to Morgan Leijström from comment #6)
> $ uname -a
> Linux svarten.tribun 6.3.9-desktop-2.mga9 #1 SMP PREEMPT_DYNAMIC Fri Jun 23
> 07:46:59 UTC 2023 x86_64 GNU/Linux

6.3.10 in the build...

OK may try later with new kernel, and then with R470 from release repo

Optimally I should learn to communicate with the computer using network when screen is black, but I am stuffed with workload

By comment 11 it really sound like we should get sddm 0.20 into Mageia
but i guess there would be no problem to switch after release
Hm except that then it is no on the Live.

PS
  If you cut down citated text it will be less to scroll
   - this will be a long bug I guess...
DS

(In reply to Morgan Leijström from comment #13)

> By comment 11 it really sound like we should get sddm 0.20 into Mageia
> but i guess there would be no problem to switch after release
> Hm except that then it is no on the Live.
> 

No, we are current in pseudo release freeze, and there is still something to review on it, better to stuck with 0.19.0-16.mga9 and keep for post-release. At most sddm-0.20.0 can go in updates_testing or backports.

(In reply to Morgan Leijström from comment #13)
> OK may try later with new kernel, and then with R470 from release repo
> 
> Optimally I should learn to communicate with the computer using network when
> screen is black, but I am stuffed with workload
> 
> By comment 11 it really sound like we should get sddm 0.20 into Mageia
> but i guess there would be no problem to switch after release
> Hm except that then it is no on the Live.
> 
> PS
>   If you cut down citated text it will be less to scroll
>    - this will be a long bug I guess...
> DS

You are right, dunno why it's was quoted 3 times, maybe because it's too late...

(In reply to Morgan Leijström from comment #8)
> (In reply to Giuseppe Ghibò from comment #7)
> > What I noticed
> > is that sometimes sddm starts but the system fails inserting the nvidia
> > modules (seems it doesn't do in time because sddm starts faster). This
> > happens with stock sddm-0.19.0-16.mga9.
> 
> I think you should open a bug on that.
> 
> Is there a missing interlock, and we are just lucky that it mostly works?
> 

BTW, with 'xdm' it didn't happen too.

Thanks for the tip, I will try XDM.

(In reply to Giuseppe Ghibò from comment #15)
> You are right, dunno why it's was quoted 3 times, maybe because it's too
> late...

I meant, in each reply, you only only need to quote the part of a comment you reply to, like I do here.

And if replying directly to the previous comment, often we do not cite at all, like my first line in this comment.

Test OK mga9-64 nvidia 470.199.02-1.mga9 from nonfree testing

Same system, *new kernel*
$ uname -a
Linux svarten.tribun 6.3.10-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Thu Jun 29 01:45:13 UTC 2023 x86_64 GNU/Linux

Tested now bot with XDM and with sddm-0.20.0-0.mga9

Incl testing suspend/resume and ctrl-alt-F3..7 tty

Performance OK

After installing nvidia470-cuda-opencl, those capabilities was recognised by BOINC


Because new kernel I also quickly tested from nonfree release, and with XDM:
 470.182.03-5.mga9
 535.54.03-2.mga9
All OK

> After installing nvidia470-cuda-opencl, those capabilities was recognised by
> BOINC

cuda-z say "CUDA Error: 00000023 CUDA driver version is insufficient for CUDA runtime version" which is expected, we only support cuda on nvidia-current.

(In reply to Morgan Leijström from comment #19)

> cuda-z say "CUDA Error: 00000023 CUDA driver version is insufficient for
> CUDA runtime version" which is expected, we only support cuda on
> nvidia-current.

That's expected, CUDA 12.1 requires at least driver 525.60, so files generated with it, can't be used with nvidia470 (older binaries, in theory, could with some limitation, but we don't have any). For supporting with nvidia470 applications for building cubins on the fly (e.g. those created by blender) one would need an older 10.2 CUDA toolkit which can be extracted and rebuilt from the svn (note that even in that case untouched cuda-z binaries won't work on nvidia470 because it need to be rebuild againt CUDA 10.2).

Still needing updates for mga8

Mageia 8 EOL

CC: (none) => nicolas.salguero
Status: NEW => RESOLVED
Resolution: (none) => OLD