MGA7 x86_64 with Plasma, Intel Core i5 3570K with Nvidia Geforce GTX 670

Updating to:
kernel-linus-5.10.19-1.mga7-1-1.mga7.x86_64.rpm
kernel-linus-devel-5.10.19-1.mga7-1-1.mga7.x86_64.rpm
kernel-linus-devel-latest-5.10.19-1.mga7.x86_64.rpm
kernel-linus-latest-5.10.19-1.mga7.x86_64.rpm

Stable system and all peripherals are OK.

MGA7-64-OK for me.

Whiteboard: (none) => MGA7-64-OK
CC: (none) => ouaurelien

advisory, added to svn:

type: security
subject: Updated kernel-linus packages fix security vulnerabilities
CVE:
 - CVE-2021-20194
 - CVE-2021-26930
 - CVE-2021-26931
 - CVE-2021-26932
src:
  7:
   core:
     - kernel-linus-5.10.19-1.mga7
description: |
  This kernel-linus update is based on upstream 5.10.19 and fixes atleast
  the following security issues:

  There is a vulnerability in the linux kernel versions higher than 5.2 (if
  kernel compiled with config params CONFIG_BPF_SYSCALL=y, CONFIG_BPF=y,
  CONFIG_CGROUPS=y, CONFIG_CGROUP_BPF=y, CONFIG_HARDENED_USERCOPY not set,
  and BPF hook to getsockopt is registered). As result of BPF execution,
  the local user can trigger bug in __cgroup_bpf_run_filter_getsockopt()
  function that can lead to heap overflow (because of non-hardened
  usercopy). The impact of attack could be deny of service or possibly
  privileges escalation. NOTE! Mageia kernel configs have HARDENED_USERCOPY
  enabled by default, making this an non-issue when using prebuilt kernels
  (CVE-2021-20194).

  An issue was discovered in the Linux kernel 3.11 through 5.10.16, as used
  by Xen. To service requests to the PV backend, the driver maps grant
  references provided by the frontend. In this process, errors may be
  encountered. In one case, an error encountered earlier might be
  discarded by later processing, resulting in the caller assuming
  successful mapping, and hence subsequent operations trying to access
  space that wasn't mapped. In another case, internal state would be
  insufficiently updated, preventing safe recovery from the error
  (CVE-2021-26930).

  An issue was discovered in the Linux kernel 2.6.39 through 5.10.16, as
  used in Xen. Block, net, and SCSI backends consider certain errors a
  plain bug, deliberately causing a kernel crash. For errors potentially
  being at least under the influence of guests (such as out of memory
  conditions), it isn't correct to assume a plain bug. Memory allocations
  potentially causing such crashes occur only when Linux is running in
  PV mode, though (CVE-2021-26931).

  An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used
  by Xen. Grant mapping operations often occur in batch hypercalls, where
  a number of operations are done in a single hypercall, the success or
  failure of each one is reported to the backend driver, and the backend
  driver then loops over the results, performing follow-up actions based
  on the success or failure of each operation. Unfortunately, when running
  in PV mode, the Linux backend drivers mishandle this: Some errors are
  ignored, effectively implying their success from the success of related
  batch elements. In other cases, errors resulting from one batch element
  lead to further batch elements not being inspected, and hence successful
  ones to not be possible to properly unmap upon error recovery. Only
  systems with Linux backends running in PV mode are vulnerable. Linux
  backends run in HVM / PVH modes are not vulnerable (CVE-2021-26932).

  It also adds the following fixes:
  - enable ACPI_EC_DEBUGFS (mga#28415)

  For other upstream fixes, see the referenced changelogs.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=28468
 - https://bugs.mageia.org/show_bug.cgi?id=28415
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.15
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.16
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.17
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.18
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.19

Keywords: (none) => advisory

Kernel: 5.10.19-1.mga7 x86_64
Intel Core i7-4790 type: MT MCP
NVIDIA GM204 [GeForce GTX 970]
x11 server: Mageia X.org 1.20.10 driver: nouveau

Forgot my own advice to change the display driver before rebooting.
This appears to be essential if you are using proprietary graphics.

So, it was a case of endlessly looping between "change of display driver,
need to reboot" and hard reset.
It is impossible to get any business done after the message because the virtual consoles switch every second.
The emergency fix is to go back to a desktop kernel and change to nouveau in the user session and try again.  Then it works, although I found all the workspaces had been wiped.

Apart from that the linus kernel works fine; NFS shares mounted at login, virtualbox works via a symbolic link to a subsidiary disk which holds the vdi's.

Leaving this up for a day or two.

CC: (none) => tarazed25

Validating.
Advisory already pushed.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0100.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED