CloudLinux OS Blog - СloudLinux 7 and CloudLinux 6 Hybrid kernel is available with a fix for MDS vulnerability
CloudLinux OS Blog

СloudLinux 7 and CloudLinux 6 Hybrid kernel is available with a fix for MDS vulnerability

MDS-fixed

CloudLinux 7 and CloudLinux 6 Hybrid kernel version 3.10.0-962.3.2.lve1.5.25.8 with a fix for MDS vulnerability is now available for download from our production repository.

Changelog:

1.5.25.7

  • CLKRN-446: backport 3.18 stable fixes to CloudLinux 7;
  • CLKRN-417: enable KABI check;
  • CLKRN-424: IOPS limits support for the noop IO scheduler;
  • CLKRN-421: fixed ext4 RO remounts;
  • CLKRN-450: xfs: avoid invalid null-pointer dereference;
  • CLKRN-147: fixed ub0 beancounter file lock charge/uncharge balance.

1.5.25.8

  • CLKRN-457: fix KABI breakage;
  • CLKRN-458: x86 MDS mitigations:
    • CVE-2018-12126 MSBDS Microarchitectural Store Buffer Data Sampling;
    • CVE-2018-12130 MFBDS Microarchitectural Fill Buffer Data Sampling;
    • CVE-2018-12127 MLPDS Microarchitectural Load Port Data Sampling;
    • CVE-2019-11091 MDSUM Microarchitectural Data Sampling Uncacheable Memory.

To update a kernel, please use the following command.

CloudLinux 7:

yum upgrade microcode_ctl && yum install kernel-3.10.0-962.3.2.lve1.5.25.8.el7

CloudLinux 6 Hybrid:

yum upgrade microcode_ctl && yum install kernel-3.10.0-962.3.2.lve1.5.25.8.el6h

Mitigation: kernel with MDS patches + microcode + disable Hyper-Threading

In multi-tenant systems where the Host has Hyper-Threading disabled, different guests should not have access to threads on the same core and should not be vulnerable. Host performance and overall availability of resources will be impacted.

In multi-tenant systems where the Host has Hyper-Threading enabled and the hypervisor is vulnerable, guests will also be vulnerable if they have Hyper-Threading disabled or not.

In multi-tenant systems where the Host has Hyper-Threading enabled and the Hypervisor is not vulnerable, guests should consider disabling Hyper-Threading to protect themselves.

Diagnose your vulnerability

Apply the patches and perform vulnerability diagnostic by running one of the following commands:

# dmesg | grep “MDS:”

OR

# cat /sys/devices/system/cpu/vulnerabilities/mds

The possible values in this file are:

  • Not affected – the processor is not vulnerable
  • Vulnerable – the processor is vulnerable, but no mitigation enabled
  • Vulnerable: Clear CPU buffers attempted – the processor is vulnerable but microcode is not updated; the mitigation is enabled on a best effort basis
  • Mitigation: CPU buffer clear – the processor is vulnerable and the CPU buffer clearing mitigation is enabled
CloudLinux 6 kernel is available with a fix for MD...
Beta: distributed replicated block device kernel m...
 

Comments 8

Guest - laoubi mohamed on Saturday, 18 May 2019 00:39

hello sir

does kernelcar support updating?

hello sir does kernelcar support updating?
Guest - AC on Saturday, 18 May 2019 02:40

[[email protected]~]# cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT vulnerable

Do I need to disable SMT?

[[email protected]~]# cat /sys/devices/system/cpu/vulnerabilities/mds Mitigation: Clear CPU buffers; SMT vulnerable Do I need to disable SMT?
Ivan Zhmud on Saturday, 18 May 2019 11:01

Laoubi Mohamed hello!

More information related KernelCare updating you can find in the latest blog post of KC team
here https://www.kernelcare.com/zombieload/

Laoubi Mohamed hello! More information related KernelCare updating you can find in the latest blog post of KC team here https://www.kernelcare.com/zombieload/
Ivan Zhmud on Saturday, 18 May 2019 11:17

Hello AC!
After updating you kernel it's not necessary but recommended. CPU bug allows to read data between CPU threads.
Therefore switched-on HT for VM is an additional possibility to attack an application on different VM’s.

Hello AC! After updating you kernel it's not necessary but recommended. CPU bug allows to read data between CPU threads. Therefore switched-on HT for VM is an additional possibility to attack an application on different VM’s.
Guest - Snek on Monday, 20 May 2019 22:32

I do not see anything on both commands:
[email protected] [~]# dmesg | grep “MDS:”
[email protected] [~]# cat /sys/devices/system/cpu/vulnerabilities/mds
cat: /sys/devices/system/cpu/vulnerabilities/mds: No such file or directory

But we use kernelcare aswell, so it's not needed to update microcode?

I do not see anything on both commands: [email protected] [~]# dmesg | grep “MDS:” [email protected] [~]# cat /sys/devices/system/cpu/vulnerabilities/mds cat: /sys/devices/system/cpu/vulnerabilities/mds: No such file or directory But we use kernelcare aswell, so it's not needed to update microcode?
Inessa Atmachian on Tuesday, 21 May 2019 08:37

Hi Snek,

Most likely you have a kernel version less than 3.10.0-962.3.2.lve1.5.25.8.el7 because it is in this version the checker has appeared. You can update your kernel till the current version specified in the post and run the check again.

Hi Snek, Most likely you have a kernel version less than 3.10.0-962.3.2.lve1.5.25.8.el7 because it is in this version the checker has appeared. You can update your kernel till the current version specified in the post and run the check again.
Inessa Atmachian on Tuesday, 21 May 2019 09:23

You can also track all KernelCare updates regarding MDS here: https://www.kernelcare.com/zombieload/

You can also track all KernelCare updates regarding MDS here: https://www.kernelcare.com/zombieload/
Inessa Atmachian on Tuesday, 21 May 2019 11:03

Snek,
If you have KernelCare, you should update microcode as well.

Snek, If you have KernelCare, you should update microcode as well.
Already Registered? Login Here
Guest
Tuesday, 25 June 2019

Captcha Image