Where
-Infinity
0
Severity
6.8
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Improper handling of overlap between protected memory ranges in some microcode for some Intel(R) Processors within Ring 0: Hypervisor may allow an escalation of privilege. Authorized adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

First published (updated )
Severity
6.5
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Gather Date Sampling (GDS) is a transient execution side channel vulnerability affecting certain Intel processor. In this flaw, a local attack using gather instruction (load from memory) may infer stale data from previously used vector registers on the same physical core.

1 / 4
Source: Red Hat
First published (updated )

On Tue Jul 25, 2023 at 6:30 PM UTC, Jeffrey Walton wrote: On Tue, Jul 25, 2023 at 2:14 PM Demi Marie Obenour <demi () invisiblethingslab com> wrote: On Tue, Jul 25, 2023 at 06:12:44PM +0100, Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. Does AMD make OS-loadable μcode patches available for client platforms, or must all μcode loading on clients be done by the firmware? If the latter, then it will take a very long time for clients to get patched, even if AMD released the updates promptly. Also, server platforms can usually reflash the firmware via the BMC, but client platforms do not have this option. Related, Ubuntu released an updated amd64-microcode around (or before) 1:45 PM EST today. My Ubuntu machines have already been patched.

I was kind of surprised to see how quickly it landed. the updated amd64-microcode only contains the fixes published to linux-firmware, which only affects epyc cpus, as noted. unless you're running epyc cpus (which is slightly unlikely so i thought i'd mention it, but apologies if that is indeed the case) you didn't actually receive any fix.

the latest kernel released today sets the chicken bit if no patched ucode is loaded which also works to mitigate the issue. (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98)

you can test this by running the zenbleed reproduction, from https://cmpxchg8b.com/files/zenbleed-v5.tar.gz

(if it outputs anything, you're vulnerable) Jeff

First published (updated )

On Tue, Jul 25, 2023 at 2:14 PM Demi Marie Obenour <demi () invisiblethingslab com> wrote: On Tue, Jul 25, 2023 at 06:12:44PM +0100, Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. Does AMD make OS-loadable μcode patches available for client platforms, or must all μcode loading on clients be done by the firmware? If the latter, then it will take a very long time for clients to get patched, even if AMD released the updates promptly. Also, server platforms can usually reflash the firmware via the BMC, but client platforms do not have this option. Related, Ubuntu released an updated amd64-microcode around (or before) 1:45 PM EST today. My Ubuntu machines have already been patched.

I was kind of surprised to see how quickly it landed.

Jeff

First published (updated )

Security Fix(es): hw: Special Register Buffer Data Sampling (SRBDS) (CVE-2020-0543) hw: L1D Cache Eviction Sampling (CVE-2020-0549) hw: Vector Register Data Sampling (CVE-2020-0548) For more details about the security issue(s), including the impact, a CVSSscore, acknowledgments, and other related information, refer to the CVE page(s)listed in the References section.Bug Fix(es): Update Intel CPU microcode to microcode-20200609 release: Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0) microcode from revision 0x61f up to 0x621; Update of 06-2d-07/0x6d (SNB-E/EN/EP C2/M1) microcode from revision 0x718 up to 0x71a; Update of 06-3c-03/0x32 (HSW C0) microcode from revision 0x27 up to 0x28; Update of 06-3d-04/0xc0 (BDW-U/Y E0/F0) microcode from revision 0x2e up to 0x2f; Update of 06-45-01/0x72 (HSW-U C0/D0) microcode from revision 0x25 up to 0x26; Update of 06-46-01/0x32 (HSW-H C0) microcode from revision 0x1b up to 0x1c; Update of 06-47-01/0x22 (BDW-H/Xeon E3 E0/G0) microcode from revision 0x21 up to 0x22; Update of 06-4e-03/0xc0 (SKL-U/Y D0) microcode from revision 0xd6 up to 0xdc; Update of 06-55-03/0x97 (SKX-SP B1) microcode from revision 0x1000151 up to 0x1000157; Update of 06-55-04/0xb7 (SKX-SP H0/M0/U0, SKX-D M1) microcode (in intel-06-55-04/intel-ucode/06-55-04) from revision 0x2000065 up to 0x2006906; Update of 06-55-06/0xbf (CLX-SP B0) microcode from revision 0x400002c up to 0x4002f01; Update of 06-55-07/0xbf (CLX-SP B1) microcode from revision 0x500002c up to 0x5002f01; Update of 06-5e-03/0x36 (SKL-H/S R0/N0) microcode from revision 0xd6 up to 0xdc; Update of 06-7e-05/0x80 (ICL-U/Y D1) microcode from revision 0x46 up to 0x78; Update of 06-8e-09/0x10 (AML-Y22 H0) microcode from revision 0xca up to 0xd6; Update of 06-8e-09/0xc0 (KBL-U/Y H0) microcode from revision 0xca up to 0xd6; Update of 06-8e-0a/0xc0 (CFL-U43e D0) microcode from revision 0xca up to 0xd6; Update of 06-8e-0b/0xd0 (WHL-U W0) microcode from revision 0xca up to 0xd6; Update of 06-8e-0c/0x94 (AML-Y42 V0, CML-Y42 V0, WHL-U V0) microcode from revision 0xca up to 0xd6; Update of 06-9e-09/0x2a (KBL-G/H/S/X/Xeon E3 B0) microcode from revision 0xca up to 0xd6; Update of 06-9e-0a/0x22 (CFL-H/S/Xeon E3 U0) microcode from revision 0xca up to 0xd6; Update of 06-9e-0b/0x02 (CFL-S B0) microcode from revision 0xca up to 0xd6; Update of 06-9e-0c/0x22 (CFL-H/S P0) microcode from revision 0xca up to 0xd6; Update of 06-9e-0d/0x22 (CFL-H R0) microcode from revision 0xca up to 0xd6. Do not update 06-4e-03 (SKL-U/Y) and 06-5e-03 (SKL-H/S/Xeon E3 v5) to revision 0xdc, use 0xd6 by default. Enable 06-2d-07 (SNB-E/EN/EP) caveat by default. Enable 06-55-04 (SKL-SP/X/W) caveat by default. Avoid find being SIGPIPE'd on early "grep -q" exit in the dracut script. Re-generate initramfs not only for the currently running kernel, but for several recently installed kernels as well. Change the URL to point to the GitHub repository since the microcode download. section at Intel Download Center does not exist anymore. Avoid temporary file creation, used for here-documents in checkcaveats.

Remedy

<tbody><tr> <th colspan="2">SRPM</th> </tr> <tr> <td class="name"> microcode_ctl-20190618-1.20200609.1.el8_1.src.rpm </td> <td class="checksum">SHA-256: eef4498ffd1eaae3c92997b6dd952f77cbba9618b79d8934477148b5bf0525ff</td> </tr> <tr> <th colspan="2">x86_64</th> </tr> <tr> <td class="name"> microcode_ctl-20190618-1.20200609.1.el8_1.x86_64.rpm </td> <td class="checksum">SHA-256: dad30171b084c04b6db0ddfe92969faa5bf038b8f07e904d81ac616be742eee0</td> </tr> </tbody>
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203