Linux Kernel 4.14 Vulnerabilities

[Caterina Haggins]

Yesplease consider adding it to the wiki as it is much better rather than posting it here. Announce your changes in the talk page before doing so, in case someone would like to disagree/consider improvements.

Lots of ink will run over this, at least lenovo has retracted a bios update for my laptop which carried an updated microcode and on their security page the availability of a fix is to be defined. Also the matter with IBRS/IBPB/STIBP is contentious, see [1].

Rookie fortunately arch already has a patched version of gcc and is your system not getting the same microcode update via early update from the kernel?

I was wondering if you had noticed any issues with it as per

Yes my system would be receiving the same microcode update via early update, but the bios I'm using already has the same microcode version so the is nothing to update. From what is described here[1] I'd say the kernel will blacklist the current microcode version, in my case 0xc2 for a mobile skylake system.

The problem is that lenovo had a bios update available with an updated microcode much sooner than intel made available the bundle with updated microcodes. I'm usually quick in updating the bios, more so in this case. Apparently if you update the bios and later revert to an earlier version the microcode updates present in the bios are not reverted, so if the microcode update stated to cause problems then you're stuck until intel releases an update that does not cause problems.

Spectre V1 the patches uses some specially crafted functions to prevent the cpu/compiler from using speculation

it requires the kernel developers to locate every vulnerable site though no need for microcode updates or special compiler support.

Spectre V2 as implemented in 4.14.y stable 4.15rc-9 uses the updated gcc for full mitigation for none skylake+ systems, older gcc produces a weaker protection.

4.16 nothing is decided if IBRS/IBPB will be used for skylate+ or some alternative approach that counts call depth.

@mcloaked

It seems there is conflicting information, in the page you linked to it says: "If you have already updated BIOS with the first microcode update and you experience reboots or unstable system behavior, you can downgrade your BIOS to the previous version." which seems to imply the microcode will be rolled back if the bios is rolled back.

However this machine has been working fine with the latest kernel 4.14.15 and microcode 0x21 with no reboot or other problems related to the new mitigations. This version of the microcode was delivered by the most recent Lenovo BIOS update so the early update process when the kernel boots has the same version so there is no early microcode update. If and when a new microcode package is released and has a version later than 0x21 then the machine will use such a more recent version. But until then arch linux runs without issue on that machine (Lenovo s540).

I was referring to the information provided by Lenovo, initially their recommendation was if the update started to cause problems to downgrade the bios, which is the recommendation from Intel, however later they have removed that advice and added to the changelog table the note I have mentioned before.

Like I have said before I haven't noticed anything amiss, but as far as I know linux isn't trying to use the new IBRS & friends instructions yet, maybe that is why. I suppose most of the systems showing problems are windows systems, at least judging by the description of the symptoms.

Apparently, Intel isn't going to issue new microcode to patch this on older CPU models like Sandybrige, Ivybridge, etc., and other older CPU's. Older machines, and motherboards not likely to get BIOS/EFI firmware updates either. If it can't be fixed through the kernel, and or browser updates, older systems are just sunk, in my opinion. It's a sad mess...

I'm sure it didn't need it but everything benefits greatly if the cpu is capable of speculative execution and gets the speculation right as it hides the latency from having to wait to fetch things from ram.

covers IBPB, STIBP, IBRS and possible uses within the kernel. My understanding is without them the kernel itself is still protected from V2 using retpoline but it does not protect VM's or userspace.

V1 and V3 are not mitigated by IBPB, STIBP, IBRS. notes the state of protection offered by 4.15 in the view of Linus.

As long as you're not a service provider and you trust local code and use a browser that has disabled SharedArrayBuffer, lowered counter granularity and provides site isolation, you should be fine. Also, run an adblocker, disable JS on sites by default and only enable it for sites that need it.

Right. That patch is for kernel only. To mitigate against v1 in userspace, you'd have to completely eliminate branch prediction which would result in an immediate 50+ slowdown of the CPU. That's why it's unrealistic that this will ever happen.

I'm not familiar with what's happening with AMD, since I don't have any of their CPUs, but I'm pretty sure AMD CPUs are also vulnerable to Spectre. From what I've read, there won't be any CPUs that are not vulnerable from Spectre in 2018 from AMD and Intel. Whatever they release this year will still be vulnerable so I wouldn't waste money just yet.

Recently, Red Hat released a security bulletin, pointing out multiple TCP-based remote denial-of-service vulnerabilities in the Linux kernel, namely, a SACK Panic vulnerability of important severity and two other vulnerabilities of moderate severity.

CVE-2019-11477 is an integer overflow vulnerability called SACK Panic, which can be triggered by a remote attacker by sending a sequence of Selected Acknowledgement (SACK) TCP packets to a vulnerable system, possibly leading to a system crash. Successful exploitation of this vulnerability will cause denial-of-service (DoS) conditions to affected systems.

CVE-2019-11479 is an excess resource usage vulnerability, which can be triggered by a remote attacker by setting a low value for the Maximum Segment Size (MSS) to cause a vulnerable system to utilize excessive bandwidths and resources. Successful exploitation of this vulnerability will cause an affected system to run with the maximum resource usage, thus degrading the system performance.

This advisory is only used to describe a potential risk. NSFOCUS does not provide any commitment or promise on this advisory. NSFOCUS and the author will not bear any liability for any direct and/or indirect consequences and losses caused by transmitting and/or using this advisory. NSFOCUS reserves all the rights to modify and interpret this advisory. Please include this statement paragraph when reproducing or transferring this advisory. Do not modify this advisory, add/delete any information to/from it, or use this advisory for commercial purposes without permission from NSFOCUS.

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

It was discovered that a new class of side channel attacks impact most processors, including processors from Intel, AMD, and ARM. The attack allows malicious userspace processes to read kernel memory and malicious code in guests to read hypervisor memory.

To address the issue, updates to the Ubuntu kernel and processor microcode are needed. Updates are announced in Ubuntu Security Notices. Meltdown/Spectre related updates have now been announced, covering updates to the kernel and to some userspace software.

In advance of security updates being released, Dustin Kirkland had provided some more details of what updates to expect in a blog post, including mention of kernel updates as well as CPU microcode, gcc and qemu updates.

The Ubuntu Security Team is maintaining their current status on these issues and an official technical FAQ that goes into detail about the specific individual vulnerability variants and their migitations under different use cases.

Note that Linux mainline and stable release updates from v4.15 (28th January 2018) and onwards include the appropriate fixes and Ubuntu kernels are based on those. As such, any versions of Ubuntu using Linux Kernel versions 4.15.0 and up are patched (including 18.04 and 18.10).

The Spectre attack vector is much harder to protect against, but is also much harder for the bad guys to exploit. While there are software patches for known attack vectors, such as an LLVM attack vector which can be patched, the core problem is that to really fix Spectre you have to alter how CPU hardware works and behaves. This makes it much MUCH harder to protect against, because only known attack vectors can really be patched. Every piece of software needs individual hardening for this issue, though, which means that it's one of those "one patch does not fix all" kind of deals.

3a8082e126