The Top 10 Linux Kernel Vulnerabilities You Should Know

March 20, 2019 Gabriel Avner

Top 10 Linux kernel vulnerabilities

As one of the pillars of the open source ecosystem, the Linux kernel is one of the most influential projects in use today.

Written back in the ’90s by Linus Torvalds, after whom the project is aptly named, it is available for use in open source projects under a GNU GPL license.

With over 823k commits and 25,215 forks listed on its GitHub page, the Linux kernel can boast an active and engaged community of over 12,000 developers including talent from tech giants like Microsoft, Google, Intel, and Red Hat.  

Given such a robust community, there are bound to be a wide range of Linux kernel vulnerabilities that turn up in the course of code reviews and simply by poking and prodding the popular project. Over the years, the Linux kernel has racked up one of the longest lists of vulnerabilities among open source projects.

While a reputation like that might scare some off developers from using this project in their own work, the reality of its continued popularity reflects the understanding that some components are just too baked into the ecosystem that no amount of vulnerabilities are going to keep developers from using them. By the same token, such a reputation actually provides a bit of street cred since it shows that the community supporting this project actually cares and is active enough to catch vulnerabilities before they become a problem. Once uncovered, the community can develop a fix and make it available for developers to implement in their products.

Unlike Windows or MacOS which push out software updates to users automatically, it is up to developers to look for Linux kernel updates on their own. This means being aware of which open source components they are using in their products and keeping track of when new vulnerabilities are discovered.   

So in case you are a user of the Linux kernel but for some reason have not been following the project for new versions that fix reported vulnerabilities, we have compiled a list of the worst vulnerabilities to hit the project in the past 10 years from the WhiteSource database.

These are all rated CVSS v2 10. We are using the CVSS v2 since some of these CVEs date back from before the introduction of CVSS v3.

So happy reading and hopefully you won’t find any of these in your products.

#1 CVE-2017-18017

Linux Kernel netfilter:xt_TCPMSS

CVSS v2: 10 High

Impacted versions: Before 4.11, and 4.9x before 4.9.36

This doozy vulnerability topped our list for Linux kernel CVEs for 2018, despite having 2017 in its ID. This is because it was first reported and had its ID reserved in 2017 before it was published by the National Vulnerability Database in January of 2018.

According to its description, the tcpmss_mangle_packet function in net/netfilter/xt_TCPMSS.c can allow remote hackers to carry out a denial of service attack (use-after-free and memory corruption. Reports show that attackers can leverage the presence of xt_TCPMSS in an iptables action to carry out an unspecified range of other impacts on your software.

This particular Linux kernel vulnerability is a real kick in the teeth given the important role that it plays in filtering network communication by defining the maximum segment size that is allowed for accepting TCP headers. Without these important controls, users open themselves up to overflow issues.

A common theme that we see throughout the Linux kernel vulnerabilities on this list is that the attacks can be carried out remotely without actions taken by the target. These remote attacks present a bigger threat than say one that requires the hacker to work locally.  

While we hope that you have updated your version since this one was published, you can check out the full list of the impacted versions.

Finally, like they usually do, the good folks in the Linux community helped us pull together a fix to help us keep our product safe and secure.

#2 CVE-2015-8812

drivers/infiniband/hw/cxgb3/iwch_cm.c

CVSS v2: 10 High

Impacted versions: Before version 4.5

A serious flaw was found in the drivers/infiniband/hw/cxgb3/iwch_cm.c of the Linux kernel when it was found to not properly identify error conditions. The result of this vulnerability was that it allowed remote attackers to execute arbitrary code or cause a denial of service (use-after-free) via crafted packets.

Info about the fix for this CVE can be viewed here.

#3 CVE-2016-10229

udp.c

CVSS v2: 10 High

Impacted versions: Before version 4.5

Short and to the point with this Linux vulnerability where the udp.c allows remote attackers to execute arbitrary code via UDP traffic that triggers an unsafe second checksum during the execution of a recv system call with the MSG_PEEK flag.

The vulnerability was found by the internal Google team which was using the component for the Android mobile OS. It showed up when users provided a buffer smaller than skb payload.

Read here about the fix.

#4 CVE-2014-2523

net/netfilter/nf_conntrack_proto_dccp.c

CVSS v2: 10 High

Impacted versions: Through 3.13.6

Another serious vulnerability raised its head for netfilter in the Linux kernel, this time by the incorrect use of a DCCP header pointer. This flaw allows remote attackers to cause a denial of service (system crash) or possibly execute arbitrary code via a DCCP packet that triggers a call to either the dccp_new, dccp_packet, or dccp_error function.  

Read here about the fix.

#5 CVE-2016-10150

virt/kvm/kvm_main.c

CVSS v2: 10 High

Impacted versions: Before 4.8.13

This use-after-free vulnerability in the Linux kernel was found in the virt/kvm/kvm_main.c’s kvm_ioctl_create_device function. It allows OS users to cause a denial of service attack.

Perhaps an even worse scenario is that hackers could use this vulnerability to gain privileges via crafted ioctl calls on teh /devkvm device.

The details of the fix can be found here.

#6 CVE-2010-2521

fs/nfsd/nfs4xdr.c

CVSS v2: 10 High

Impacted versions: Before 2.6.34-rc6

Hold on tight for this one. Multiple buffer overflows in fs/nfsd/nfs4xdr.c in the XDR implementation in the NFS server in the Linux kernel allow remote attackers to cause a denial of service. There is also a possibility that attackers can execute arbitrary code via a crafted NFSv4 compound WRITE request, related to the read_buf and nfsd4_decode_compound functions.

In their notes, researchers noted that “When read_buf is called to move over to the next page in the pagelist of an NFSv4 reqest, it sets argp->end to essentially a random number, certainly not an address within the page which argp->p now points to.”

They found this interesting because they said that subsequent calls to READ_BUF will think there is much more than a page of spare space so it can expect to fall off the end of the second page. They note that they have never encountered this situation in testing because “typically the only operations which use more than two pages are write-like operations which have their own decoding logic.”

View the fix details and the rest of their analysis here.

#7 CVE-2017-13715

net/core.flow_dissector.c

CVSS v2: 10 High

Impacted versions: Before 4.3

The __skb_flow_dissect function in net/core.flow_dissector.c does not ensure that n_proto, ip_proto, and thoff are initialized. This can allow hackers to cause a denial of service or even execute arbitrary code via a single crafted MPLS packet.

Check out this short and sweet fix to stay secure.

#8 CVE-2016-7117

CVSS v2: 10 High

Impacted versions: Before 4.5.2

net/socket.c

Here we find ourselves with yet another use-after-free vulnerability in the __sys_recvnnsg function in net/socket.c opens the door for remote attackers to execute arbritrary code via vectors involving a recvmmsg system call that is mishandled during error processing.

Based on the reports, this Linux kernel vulnerability was found by Dmity Vyukov from Google’s team of researchers.

See his findings and the fix here.

#9 CVE-2009-0065

net/sctp/sm_statefuns.c

CVSS v2: 10 High

Impacted versions: Before 2.6.28-git8

This is the oldest CVE Linux kernel vulnerability to make our list, packing a punch that we still remember from 2009 until today.

The buffler overflow in net/sctp/sm_statefuns.c in the Stream Control TRansmission Protocol (aka sctp) implementation can allow remote attackers to have an undetermined impact via an FWD-TSN chunk with a large stream ID.

Basically this is a failure to perform the validity check which can cause a memory overflow.

While the researchers either chose not to expand on or simply didn’t know what the impact was for these kinds of attacks, we can assume that it wasn’t going to be a friendly one.

Find what you need to know to implement the fix here.

#10 CVE-2015-8787

net/netfilter/nf_nat_redirect.c

CVSS v2: 10 High

Impacted versions: Before 4.4

It would not feel right to finish this list off without a final netfilter vulnerability. So apparently the nf_nat_redirect_ipv4 function in net/netfilter/nf_nat_redirect.c could allow some miscreant remote attackers to cause a denial of service or have some other kind of unknown impact by sending certain IPv4 packets to an incompletely configured interface.

Find the fix here.

The researchers note that this issue is related to a Linux kernel vulnerability from back in 2003, CVE-2003-1604. We should remember that just because one vulnerability gets resolved, the Linux kernel plays such a key role in the open source space that some issues are likely to reappear in different forms from time to time.

Keep Your Versions Up To Date To Avoid Linux Kernel Vulnerabilities In Your Software

Hopefully, you have had a chance to take a look through your inventory and dependencies to see if you are using any of these components in the Linux kernel. To ensure you are avoiding these or other vulnerabilities, you should be using the latest version and your products are secure.

If you want to read more about vulnerabilities that were found in the Linux kernel during 2018, then feel free to check out our post on that as well.   

Do you think that we missed an important vulnerability? Let us know by tweeting at us or sharing this on your preferred social platform.

 

Previous Article
Kubernetes Pod Security Policy Best Practices
Kubernetes Pod Security Policy Best Practices

Next Article
Is One Programming Language More Secure Than The Rest?
Is One Programming Language More Secure Than The Rest?