Linux Kernel - CVE-2017-5754 , CVE-2017-5753 , CVE-2017-5715

You can ofcourse always update, but wait until later to reboot.
But the update isn't securing the server yet.
And delaying the restart could perhaps cause unexpected issues one might not relate back to the Kernel when a reboot is done later in time.
 
The latest available kernel 3.10.0-714.10.2.lve1.4.79.el7.x86_64 from CloudLinux 7 is bootable fine under Xen version 4.7:

Code:
[root@vps1 ~]# uname -ir
3.10.0-714.10.2.lve1.4.79.el7.x86_64 x86_64

[root@vps1 ~]# uptime
 06:19:20 up 2 min,  1 user,  load average: 0.39, 0.30, 0.12


[root@vps1 ~]# grep -iE "hypervisor|xen|kvm|vmware" /var/log/dmesg --color
[    0.000000] DMI: Xen HVM domU, BIOS 4.7.2-2.5 05/11/2017
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.7.
 
Hello,

Las weekend we updated our OpenVZ nodes to the latest patched CentOS6 Kernel RHEL6 042stab127.2. After updating the kernel, we are seeing some big load spikes on a couple of nodes.

All vps servers running on our nodes are centos6, have directadmin as control panel and are managed by us for our clients. We have seen the following strange issues:

- On one node we had to disable clamav on all vps servers because of huge CPU spikes. All of the vps servers would have clamav running simultaneously, consuming huge amounts of CPU and driving the node load above 200 and making almost everything inaccessible.
- On this same node we have had to change the directadmin nightly tally time inside each vps because load would spike above 100 when this process was running on all vps servers simultaneously.
- On another node, we have seen some big load spikes when csf firewall runs a directory check.

This is what we have been observing during this week. The normal load doesn't appear to have changed on our nodes after the new kernel was installed, but it appears that some processes are causing huge load spikes.

Has anyone else seen strange things happening on their centos6 servers after installing the latest kernel?

Regards!
 
New updates are available;

iwl100-firmware.noarch 39.31.5.1-58.el7_4 updates
iwl1000-firmware.noarch 1:39.31.5.1-58.el7_4 updates
iwl105-firmware.noarch 18.168.6.1-58.el7_4 updates
iwl135-firmware.noarch 18.168.6.1-58.el7_4 updates
iwl2000-firmware.noarch 18.168.6.1-58.el7_4 updates
iwl2030-firmware.noarch 18.168.6.1-58.el7_4 updates
iwl3160-firmware.noarch 22.0.7.0-58.el7_4 updates
iwl3945-firmware.noarch 15.32.2.9-58.el7_4 updates
iwl4965-firmware.noarch 228.61.2.24-58.el7_4 updates
iwl5000-firmware.noarch 8.83.5.1_1-58.el7_4 updates
iwl5150-firmware.noarch 8.24.2.2-58.el7_4 updates
iwl6000-firmware.noarch 9.221.4.1-58.el7_4 updates
iwl6000g2a-firmware.noarch 17.168.5.3-58.el7_4 updates
iwl6000g2b-firmware.noarch 17.168.5.2-58.el7_4 updates
iwl6050-firmware.noarch 41.28.5.1-58.el7_4 updates
iwl7260-firmware.noarch 22.0.7.0-58.el7_4 updates
linux-firmware.noarch 20170606-58.gitc990aae.el7_4 updates
microcode_ctl.x86_64 2:2.1-22.5.el7_4 updates

The new microcode update reverts the previous patch because of system instabilities and CentOS new recommends to install patches from hardware manufacturers. Great "solution"..:confused:
 
Back
Top