mga8, x64
Quad Core Intel Core i7-4790
GM204 [GeForce GTX 970] driver: nvidia 470.74

No problems except the need to rebuild the grub boot menu.

Mate running OK, networking, NFS and NAS, video, audio, bluetooth, wifi printing, dvb_T2 TV.  Virtualbox works.

CC: (none) => tarazed25

Thanks for the test, flushing out...

Advisory, added to svn:

type: security
subject: Updated kernel-linus packages fix security vulnerabilities
CVE:
 - CVE-2022-0001
 - CVE-2022-0002
 - CVE-2022-23036
 - CVE-2022-23037
 - CVE-2022-23038
 - CVE-2022-23039
 - CVE-2022-23040
 - CVE-2022-23041
 - CVE-2022-23042
 - CVE-2022-23960
src:
  8:
   core:
     - kernel-linus-5.15.28-1.mga8
description: |
  This kernel-linus update is based on upstream 5.15.28 and fixes at least
  the following security issues:

  Non-transparent sharing of branch predictor selectors between contexts
  in some Intel(R) Processors may allow an authorized user to potentially
  enable information disclosure via local access (CVE-2022-0001).

  Non-transparent sharing of branch predictor within a context in some
  Intel(R) Processors may allow an authorized user to potentially enable
  information disclosure via local access (CVE-2022-0002).

  Several Linux PV device frontends are using the grant table interfaces
  for removing access rights of the backends in ways being subject to
  race conditions, resulting in potential data leaks, data corruption
  by malicious backends, and denial of service triggered by malicious
  backends:

  blkfront, netfront, scsifront and the gntalloc driver are testing
  whether a grant reference is still in use. If this is not the case,
  they assume that a following removal of the granted access will always
  succeed, which is not true in case the backend has mapped the granted
  page between those two operations. As a result the backend can keep
  access to the memory page of the guest no matter how the page will be
  used after the frontend I/O has finished. The xenbus driver has a
  similar problem, as it doesn't check the success of removing the
  granted access of a shared ring buffer (blkfront: CVE-2022-23036,
  netfront: CVE-2022-23037, scsifront: CVE-2022-23038,
  gntalloc: CVE-2022-23039, xenbus: CVE-2022-23040)

  blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront,
  and pvcalls are using a functionality to delay freeing a grant reference
  until it is no longer in use, but the freeing of the related data page
  is not synchronized with dropping the granted access. As a result the
  backend can keep access to the memory page even after it has been freed
  and then re-used for a different purpose (CVE-2022-23041).

  netfront will fail a BUG_ON() assertion if it fails to revoke access in
  the rx path. This will result in a Denial of Service (DoS) situation of
  the guest which can be triggered by the backend (CVE-2022-23042).

  Certain Arm Cortex and Neoverse processors through 2022-03-08 do not
  properly restrict cache speculation, aka Spectre-BHB. An attacker can
  leverage the shared branch history in the Branch History Buffer (BHB)
  to influence mispredicted branches. Then, cache allocation can allow
  the attacker to obtain sensitive information (CVE-2022-23960).

  It was found that the default LFENCE-based Spectre v2 mitigation on
  AMD cpus is insufficient to mitigate such attacks. Becuse of that,
  the code have been switched to use generic retpolines on AMD cpus
  by default.

  For other upstream fixes, see the referenced changelogs.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=30158
 - https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00598.html
 - https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/spectre-bhb
 - https://seclists.org/oss-sec/2022/q1/173
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.27
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.28
[tmb@tmb-laptop advisories]$

CC: (none) => sysadmin-bugs
Whiteboard: (none) => MGA8-64-OK
Keywords: (none) => advisory, validated_update

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

https://advisories.mageia.org/MGASA-2022-0101.html

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