1

Understanding Linux Kernel Vulnerabilities

Alireza Shameli-Sendi
Faculty of Computer Science and Engineering, Shahid Beheshti University (SBU), Tehran, Iran
Email: {a shameli@sbu.ac.ir}

Abstract—Protecting the Linux kernel from malicious activities is of lab environment that can later be used as a baseline for
paramount importance. Several approaches have been proposed to future comparisons [1]. An intrusion is reported if a sig-
analyze kernel-level vulnerabilities. Existing studies, however, have a nificant deviation is noted [7]. Building effective host-based
strong focus on the attack type (e.g., buffer overflow). In this paper, we detection systems requires a good understanding of the
report on our analysis of 1,858 Linux kernel vulnerabilities covering a
host system to select aspects of the system that need acute
period of Jan 2010-Jan 2020. We classify these vulnerabilities from the
attacker’s view using various criteria such as the attacker’s objective, the
monitoring. Monitoring the entire kernel is not effective
targeted subsystems of the kernel, the location from which vulnerabili- because of the large amount of collected information and
ties can be exploited (i.e., locally or remotely), the impact of the attack the high overhead imposed by most monitoring techniques.
on confidentiality, system integrity and availability, and the complexity Since our focus is on Linux-based platforms, we begun our
level associated with exploiting vulnerabilities. Our findings indicate the research by studying the possible ways by which the Linux
presence of a large number of low-complexity vulnerabilities. Most of kernel can be compromised.
them can be exploited from the local system, leading to attacks that can The review of the literature shows that existing studies
severely compromise the kernel quality of service, and allow attackers [14], [15], [19], [22] have either a broader scope by classifying
to gain privileged access.
attacks independently from the platform or a strong focus
Index Terms—Software Security, Linux Kernel Vulnerability, Vulnerabil- on particular attack types (e.g., integer overflow or missing
ity Taxonomies. pointer check). In addition, many studies are also outdated.
Nevertheless, we recognize the value of these studies in
helping us gain knowledge of the security threats the kernel
1 I NTRODUCTION is subjected to. To build on existing work, we analyze, in
Attacks on operating system kernels may cause serious this paper, 1,858 Linux kernel (ver. 1.2.0-5.4) vulnerabilities
damages to the entire host. The kernel consists of a large from January 2010 to January 2020. We use the National
code base essential for the proper operation of various Vulnerability Database (NVD) [6] as the main source of data.
interconnected subsystems of the operating system. User ap- The objective of our analysis is to answer the following
plications interact with kernel subsystems typically through research questions:
system calls, network connections, and I/O control mecha-
• RQ1. What is the cause and effect relationship be-
nisms [3], [29]. Design faults in the kernel often lead to secu-
tween vulnerabilities in the kernel and the attacker
rity vulnerabilities that attackers can exploit to bring down
objectives? In many cases, there is not strong rela-
the system or, even worse, gain access to unauthorized data
tionship between these two concepts. For example,
[5].
the objective of an attacker who perform a ”buffer
Techniques that ensure kernel security are therefore
error” is executing arbitrary code to cause a denial
needed. In the past 25 years, a large number of developers
of service (DoS). He probably does not care how
have contributed to the development of the Linux operating
this is done. Vulnerabilities impact differently the
system [2]. The kernel code has always been changing based
operating system, providing all sorts of possibilities
on critical requests and user compliance and hardware.
to attackers. Answering this question will allow us
With 25 years of vulnerability data now available [6], the
to understand which vulnerabilities are exploited the
Linux kernel has the most CVEs (Common Vulnerabilities
most by attackers and for what purpose (see Section
and Exposures) reported for it. This emphasizes the impor-
3.1).
tance of analyzing the vulnerabilities of the Linux operating
system to uncover trends and potential risks, which is the
objective of this paper. Note that we have only focused • RQ2. Which Linux operating system components are
on the vulnerabilities of the last decade (January 2010 to more vulnerable? Identifying the vulnerable compo-
January 2020). nents can help Linux developers to improve related
One of the key aspects of host-based anomaly detec- codes in the subsequent releases (see Section 3.2).
tion techniques is to study what constitutes a normal or
healthy behaviour of the system. The common approach • RQ3. How many vulnerabilities of the kernel can be
is to measure various characteristics of the system in a exploited locally vs. remotely? Local exploitation re-
 2

quires a direct login session to the host system, while Chen et al. [16] classify information from 141 previously
remote exploitation is achieved through a remote documented kernel vulnerabilities. Then, they analyze how
network. Knowing the percentage of vulnerabilities current runtime prevention techniques (e.g., software fault
that can be exploited remotely or locally is necessary isolation, code integrity checking, user mode drivers, and
in order to design appropriate mitigation solutions memory tagging/tracking) are used to prevent these vul-
(see Section 3.3). nerabilities. The authors also discuss the applicability of
compile-time static code analysis tools to detect bugs in the
• RQ4. What is the complexity level required to ex- kernel.
ploit a given vulnerability? Running attacks requires Mokhov et al. [17] introduce taxonomy of methods to
adequate knowledge of the attack. Vulnerabilities mitigate vulnerabilities in the kernel. They have examined
that are hard to exploit require the design of more 290 documented vulnerabilities from 2002-2007 in the kernel
complex attacks. This question allows us to under- and classified them by the type of error (e.g., design, input
stand the complexity of the attacks by examining the validation, buffer overflow etc.). Different categories are
complexity level of exploiting the Linux vulnerability established on the basis of how the vulnerabilities were
(see Section 3.4 and Section 3.6). patched. Some of these resulting categories include chang-
ing the data type, precondition validation before execu-
tion, zeroing memory before use, input validation and fail
• RQ5. How many attacks have a partial or full impact
safe default initialization. These categories are then further
on CIA (confidentiality, integrity and availability)
combined with current programming guidelines to form
attributes? It is important to know which attribute
security-oriented programming guidelines for the Linux
is more vulnerable in Linux operating system in case
kernel.
of attacks. For example, if most of the vulnerabilities
Argyroudis et al. [23] analyze the current countermea-
affect the availability attribute, the availability of
sures built into operating system kernels to prevent com-
services hosted on the Linux operating system are
mon kernel exploits such as NULL pointer dereferences.
at risk, and there should be a mechanism to handle
Subsequently, the paper overviews various memory corrup-
that (see Section 3.5).
tion mitigation techniques and proactive mitigations used
by various operating systems (Linux, Windows, Mac OS X,
• RQ6. Based on the studied vulnerabilities, what iOS and Android). Techniques that are used to bypass such
should be the characteristics of a proper intrusion re- kernel protection mechanisms are also briefly discussed.
sponse system to prevent potential attacks? In many Our work is different from prior studies in two ways.
cases, it is not possible to fix all vulnerabilities due First, we cover a wider range of attacks. The second differ-
to time and cost constraints. Therefore, the design of ence is that we describe the vulnerabilities from different
a proper intrusion response system is needed for an angles such as the attack category, access complexity, im-
operating system so that it can respond appropriately pact, etc. The objective is to allow the reader to make an
to attacks (see Section 5). informed assessment of the kernel’s security weaknesses.
We believe that the answer to these questions can enable
security experts to gain a better understanding of Linux 3 C LASSIFICATION OF L INUX K ERNEL V ULNERA -
kernel vulnerabilities and their effects. Thus, the results of
BILITIES
this study are expected to contribute to the building of better
defence mechanisms. The rest of this paper is structured The Linux kernel vulnerability dataset used in our study
as follows: In Section 2, we report on related work. In comes from NVD, a US Government repository of vul-
Section 3, we present the criteria by which we classified the nerability information [6]. NVD contains a set of docu-
attacks along with the analysis of the attacks. Discussion mented vulnerabilities covering a wide range of software
and implications of this paper is presented in Section 4. systems. Each vulnerability is recorded using the following
Section 5 presents our conclusion of statistics along with attributes:
related recommendations. We conclude our work in Section • A unique ID known as the Common Vulnerabilities
6. and Exposures (CVE) ID.
• A short description that contains information about
2 R ELATED W ORK the affected software, the attack method, the cause
of the vulnerability, and the objective that can be
There exist many studies that aim to classify attacks. They
achieved upon successful exploitation.
cover a wide range of computing platforms ranging from
• A vulnerability score calculated using a standardized
general-purpose computing systems to wireless networks
scoring mechanism.
(e.g. [14], [15], [19], [22]). In this section, we only report on
• The potential impact on confidentiality, integrity and
studies relevant to Unix-like systems.
availability if the vulnerability is exploited.
Bishop presents a general taxonomy of Unix system
• The complexity level for accessing and exploiting the
and network daemon vulnerabilities [20]. The goal of their
vulnerability.
work is to describe vulnerabilities in a format useful to
intrusion detection and prevention techniques. Further, the A search query on the NVD yields approximately
paper discusses methods for finding these vulnerabilities 123,454 vulnerability records for all products since 1999.
and preventing their exploit. A total of 1,858 vulnerabilities affecting the Linux kernel
 3

have been documented in the NVD from January 2010 to TABLE 1: Criteria by which we classified vulnerabilities
January 2020. The breakdown of the vulnerabilities per year
Category Description
is reported in Figure 1.
Attack Objective The vulnerability type
390 Affected Kernel Components The attacker target
366 component in Linux kernel
360
330 Attack Origin Represents the attacker
Number of Vulnerabilities

geographical location to
300 284
deploy his attack
270
240
247 Attack Complexity Situations which are
required to exploit
210
vulnerability
180 167 162
147 150 Attack Impact On CIA Impact on Confidentiality,
150 143
Integrity, and Availability
120 115
criterion
90 77
Attack Privilege Security step to allow
60 access to certain resource
30
Attack Severity Level Presents a score number
0 for each vulnerability
20

20

20

20

20

20

20

20

20

20
1

1
0

9
Year
the entire Linux kernel as noted by Chen et al. [16]. The
Fig. 1: Year-wise breakdown of NVD vulnerability dataset authors showed how three different vulnerabilities includ-
ing DoS vulnerability are used together to compromise the
As shown in Figure 1, the maximum number of vul- Linux kernel. Figure 2 shows that vulnerabilities that allow
nerabilities have been detected in 2016 and 2017, over the attackers to obtain sensitive information, Information Leak
last ten years. We can see that the number of detected type, come in the first position with a total of 240 out of
vulnerabilities in 2018 is relatively low compared to 2016. 1,858 (12.9%) vulnerabilities.
The main reasons for this trend are: 1) In 2012, there were We also investigate the distribution of new vulnerability
16 types of vulnerabilities in the Linux operating system. types per year. As we can see in Figure 3, the number of
2) A year later, in 2013, vulnerabilities on driver, net, and vulnerability types until end of 2010 was nine. This value
arch components of Linux saw an important increase. 3) reached 61 by the end of December 2019. Moreover, since
The number of vulnerabilities discovered in 2016 and 2017 2010, the number of vulnerability types has seen an unusual
has intensified as a result of the emergence of many new growth.
types of vulnerabilities, and the increase in attacks on the
components of driver and net. 4) In 2018, vulnerabilities
65
behind attacks on many components were fixed, especially 60 59
61
Number of Vulnerabilities Type

those targeting to driver component. 55

55

Table 1 shows the criteria by which we classified the 50

Linux kernel vulnerability dataset. We selected these crite- 45
ria to answer the research questions and provide a good 40
35
understanding of the effect of vulnerabilities from different 35

angles. We elaborate on each criterion and present the 30

26 27
25
results of classifying the Linux kernel vulnerabilities in the
20 18
subsequent sections. 16
15 13
10 9
3.1 Attack Objective 5

Through the examination of NVD vulnerability records for 0

20

20

20

20

20

20

20

20

20

20

the Linux kernel, we found that the vulnerabilities type can

10

11

12

13

14

15

16

17

18

19

be grouped into 61 categories. It should be noted however Year

that some exploited vulnerabilities may lead to combined
effects such as gaining privileges and bypassing security Fig. 3: Growth of the number of vulnerability types from
restrictions. January 2010 to January 2020
Figure 2 shows the results of classifying the Linux kernel
vulnerabilities over the last ten years. Vulnerabilities for In the following, we examine the status of the number of
which we could not find information regarding the vulnera- detected vulnerabilities occurring in each type, over the last
bility type in the NVD repository are 161 vulnerabilities out ten years.
of 1,858 (about 8.6%). Analysis of vulnerabilities shows that The 12 most frequent types have been selected from Fig-
a high number of them impact on availability criteria which ure 2 and their trends are shown in Figure 4. As we can see
lead to DoS attacks. These attacks alone do not cause loss in Figure 4(a), the information leak type had 29 registered
of integrity or breach of system confidentiality. DoS vulner- CVE in 2010 and still is an important vulnerability type.
abilities, however, should not be regarded as low risk since This type had 55 vulnerabilities in 2017. In seven types of
the combination of DoS with other attacks can compromise vulnerabilities, most of the vulnerabilities occurred in 2010.
 4

240
250 195
Total 200 169 156
150 128
105 103 107
81
100 67
39 52 42 31
50 2 2 8 10 1 10 6 2 5 2 1 12 6 8 14 1 1 2 1 7 1 17 1 1 2 2 3 1 3 3 3 11 7 4 1 1 1 4 2 1 1 2 1 2 1 1 4
0

Info
NULLrmatio
Acce Pointn Lea
Resoss Coner Dek
Inpuurce Mtrolsrefere
Bufft Valianage
Numeer Errdatioment
Race c Er s
Code Condirors
Conf Injections
Resoigurattion
Infiurce Cion
Crosnite Lonsum
Imprs−siteoop ption
Crypoper A Scri
Accetograputhenpting
Privss Conhic Iticati
Formilege trol ssues on
Use at StrManag
PathAfter ing ement
Out− TraveFree
Crosof−boursal
Links−Sitends R
DEPR Follo Requead
7PK−ECATEDwing est Fo
DataSecuri: Cod
Doub Procety Fee
Secule Fressingatures
Out− ity C
Injeof−bouheck
Intection nds W
Impr r Ov
Permoper Aerflo
7PK−issionuthorw
CrypErrors Issuizatio
Clastograp
TOCTsic Buhic S
DataOU Racffer gnatu
Buff Authee ConOverflre
Incoer Siznticiditionow
Imprrrect e
Allooper CType
Exce ation eck Conver
Reacptiona of Rfor Unsion
Arrahable l Conesourcusual
Missy IndeAsserditiones
Diviing Rex
Missde By lease
Releing AuZero of Re
Incoase ofthori
Log rrect Invazation
ResoFiles Calcu id Po
Permurce S
Inteissionhutdo
Clea er Un Assiwn
Imprrtext derflgnment
Incooper ITransow
XML rrect nitiamissio
InfoExternAutholizatin
Commrmatioal Enrization
Defaand Inn Exptity Ron
r

ult
i

Pere
o

j ct osure efer
r

misi
sion
n

es
i

ty

tion s

l
lati inte

on
E

i
rror

te

s
on
nce

rger

sour
y

ce

ence
Fig. 2: Vulnerabilities distribution by their type

The only vulnerability type that has been decreasing over The ”arch” component had undergone a large number of
the past ten years is the numeric errors type. From Figure 4, changes from 2009 to 2013, but then the code commits
we can see that five vulnerability types have been raised for the ”arch” source code declined with moderate slope
in recent years: Use After Free, NULL Pointer Dereference, [13]. To satisfy requirements of hardware manufacturers, the
Out-of-bounds Read, Out-of-bounds Write, and Uncontrolled ”driver” component needs to keep growing, which results
Resource Consumption. Vulnerabilities such as logical errors, in a large number of changes. In 2017, the number of code
checks missing on arguments and privileges become rare. Thus, commits for the driver component passed to 400, the highest
the kernel heap related vulnerabilities have been targeted number of commits in the last decade. In the Linux kernel
by attackers, recently. 4.9 (released in December 2016), ”two-thirds of the bulk
of changes are drivers1 ”. The core components of Linux
3.2 Affected Linux Kernel Components (e.g., ”mm”, ”kernel”, ”ipc”), after more than two decades
of evolution, appear to have become mature and have less
This category denotes the Linux kernel components that are
development activity. Therefore, as seen in Figure 6, the core
targeted by the attackers. By component, we mean a sub-
components have less number of vulnerabilities detected
system of the Linux kernel (e.g., arch, net, fs, crypto, etc.).
compared to the peripheral components such as ”driver”.
The main Linux kernel components are shown in Figure 5 We also examine the relationship between the vulner-
(for more details on these components, please refer to [14]). abilities discovered in each vulnerability type and kernel
Attacks exploit vulnerabilities found in specific functions versions. Figure 7 shows this for the most important types
within the same component of the kernel. (see Figure 2). We found that Linux version 5.* is a much
In Figure 5, we show the distribution of the attack targets safer version compared to other versions, although it is a
for each kernel component. For some vulnerabilities, the new version (released march 2019). Note that the current
NVD lacks information on the affected functions, which are version of the Linux Kernel is still version 5.5. It may be
508 vulnerabilities out of 1,858 (27%). We excluded these possible much more vulnerabilities can be found in future.
vulnerabilities in this section. It can be observed from Figure If we ignore the version 5.*, which is new, regarding the
5 that the drivers, fs, and net components alone account access control vulnerability type, the most retrofitting has
for 906 of the total vulnerabilities. This is worrisome since been done from versions 3.* to 4.*. Moreover, the number of
these components are vital to the functioning of the OS. The vulnerabilities in the five types of vulnerabilities shown in
drivers, fs, and net components account about 50%, 7%, and (Figure 7(h)-(l)) have not been reduced in new versions of
4% of the kernel size. Not all drivers are however needed Linux.
during operation. It is therefore hard to assess the true
impact of driver vulnerabilities on a system in operation.
Figure 6 also shows evolution of vulnerability detec- 3.3 Attack Origin
tion for each Linux Kernel component over the last ten There are four ways by which a vulnerability can be ex-
years. Important and notable points about this figure are: ploited:
1) The vulnerabilities of the ”arch” component have de-
• Locally from within the system (login session to the
creased since 2014, 2) The vulnerabilities discovered for the
system)
”drivers” component in 2019 have been remarkably high
• From the collision domain/broadcast domain of the
compared to the other years, and 3) the ”arch”, ”drivers”,
target system network
”fs”, ”kernel”, ”mm”, and ”net” components have contained
vulnerabilities in all the years. The frequent changes to the 1. //www.linux.com/news/linux-kernel-49-here-and-its-largest-
source code are clearly one of the factors behind this finding. release-ever
 5

80 80 80

60 60 60
No.

No.

No.
40 40 40

20 20 20

0 0 0
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019

(a) Information Leak (b) Input Validation (c) Access Control

80 80 80

60 60 60
No.

No.

No.
40 40 40

20 20 20

0 0 0
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019

(d) Resource Management (e) Buffer Errors (f) Numeric Errors

80 80 80

60 60 60
No.

No.

No.
40 40 40

20 20 20

0 0 0
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019

(g) Race Conditions (h) Out-of-bounds Write (i) Use After Free
80 80 80

60 60 60
No.

No.

No.

40 40 40

20 20 20

0 0 0
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019

(j) NULL Pointer Dereference (k) Out-of-bounds Read (l) Uncontrolled Resource Consumption

Fig. 4: The result of each vulnerability type trend over the last ten years.

• From a remote location such as public Internet cludes the origin of an attack as one of the scoring pa-
• Physically by manipulating the vulnerable compo- rameters. We used this indicator to categorize the location
nent (direct physical access to the asset) from which a vulnerability can be exploited. As we can see
in Figure 8, approximately 75.6% of the total number of
It should be noted that a vulnerability that is exploitable
vulnerabilities (1,405/1,858) are locally exploitable, which
from a remote location is also exploitable from the other
means that exploitation would require some sort of local
two network locations, whereas the reverse is not valid.
access to the system.
Attackers would need to originate their exploits from one
of these four location points. Studying the distribution of
kernel vulnerabilities across the four locations would allow
security experts to examine whether host based prevention
system or network based prevention system must be given
more priority to prevent the occurrence of these exploits.
The Common Vulnerability Scoring System (CVSS) in-
 6

520 508 of attacks. Examination of these results shows that over 81%
480 (1,508/1,858) of vulnerabilities are low-complexity exploits.
Number of Vulnerabilities
440
403
To push this further, we examined the distribution of
400
vulnerabilities based on their complexity and the attack
360
320 303
origin. We found that about 73% (1,103/1,508) of the vulner-
280 abilities of low complexity are exploitable locally (see Fig-
240 220 ure 10), which enforces the need for advanced host-based
200
intrusion detection techniques. In addition, the fact that
160
120
120 most kernel vulnerabilities discovered are easily exploitable
80
79
50
hints that developers and security experts must place even
39
40 26 23 14 12 10
28
3 10 3 7
more emphasis on security during kernel design to help
0
pro-actively address and uncover these vulnerabilities the
ar
bl
cr
dr o
fs rs
in
ip e
ke
lib
m
ne
se
so rity
to d
vi
pr
de
ot
rt
oc

cl
c
yp

ol

he
ch

iv

oc
r

c
un
system is deployed.
t

v
ne
ud

u
e

s
k
t

r
l

Fig. 5: VulnerabilitiesLinux
distribution by Linux kernel compo-
Kernel Components 3.5 Attack Impact on CIA
nents In this category, we classify the impact of vulnerabilities on
CIA (confidentiality, integrity, availability) attributes. Con-
fidentiality refers to restricting information to authorized
1500 1405 users. Integrity ensures that the information is presented as
Number of Vulnerabilities

intended by the owner. Availability refers to the ability of

1200 the system to provide services. The distribution of attacks
bases on their impact on CIA is shown in Figure 11. As
900
expected, the presence of a large number of vulnerabilities,
600 causing denial of service, results in attacks that have direct
impact on the availability of the system.
316
300 We also found that only a small number of vulnerabili-
55 82 ties cause low impact, i.e., the impact of these vulnerabilities
0 cannot be controlled by the attacker. In most cases, the
Lo

Ad

Ph
et
ca

impact is high, meaning that a potential attacker can control

ja

ys
w

ce
l

ic
or

al
nt
k

−n

what components of the kernel to compromise, increasing

et
w
or

the likelihood of a targeted attack.

k

Fig. 8: Vulnerability distribution by origin of attack As we can see in Figure 11, the majority of vulnerabilities
have high impact on at least one of the CIA criteria. The
availability impact is about 48% more than the impact on
The high prevalenceLinux Kernel
of locally Components
exploitable vulnerabilities
confidentiality, and the confidentiality impact is about 33%
suggests that host-based intrusion prevention techniques
more than the impact on integrity. These results show that
should be given attention, since the most sophisticated
attackers can choose from a large set of vulnerabilities to
network based intrusion prevention system would serve
launch targeted attacks that negatively impact any of these
little purpose in the prevention of such local attacks.
attributes.
Figure 12 shows the relationship between the attack
3.4 Attack Complexity impact and the origin of the attack. As we can see, a
significant number of vulnerabilities that impact confiden-
The level of expertise of the attackers and target system
tiality, integrity and availability are locally exploitable. The
requirements to exploit vulnerabilities vary from vulnera-
ratio of locally exploitable vulnerabilities that cause high
bility to another one. Some vulnerabilities may, for example,
impact to the total number of vulnerabilities is high (42%,
require some services to run on the target system, specific
28%, and 69% for confidentiality, integrity and availability,
system architecture, the presence of a particular device
respectively).
driver, etc. The CVSS Version 2 defines three complexity
From the above statistics, it is evident that in most cases,
levels associated to each vulnerability: low, medium, or high.
attackers can control the impact that vulnerabilities will
Low complexity means that the exploitation is trivial and
have on the kernel. Since the impact can be controlled,
can be performed using readily available scripts. Medium
targeted attacks towards a specific function can result, im-
rating means that some pre-defined conditions must be
plying that the quality of service offered by the kernel is
met. High complexity is used when the vulnerability is
likely to be severely affected.
exploitable only in a specific environment, or when specific
conditions (such as elevated privileges or the presence of
additional vulnerable components) are met. 3.6 Attack Privilege
In the CVSS Version 3, only two levels of complexity This category describes the level of privileges an attacker
have been defined: low and high. Note that our evaluation is must have to successfully exploit the target, defined as
based on Version 3. If a vulnerability is scored using Version None, Low, or High, in the NVD Dataset. Attacks that do
2 then we consider low and medium as being low. Figure 9 not require special privileges are classified as None. A low
shows kernel vulnerabilities with respect to the complexity privilege level means that the attacker needs the normal user
 7

160 160 160 160

140 140 140 140
120 120 120 120
100 100 100 100
No.

No.

No.

No.
80 80 80 80
60 60 60 60
40 40 40 40
20 20 20 20
0 0 0 0
20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20
10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19
(a) arch (b) block (c) crypto (d) drivers
160 160 160 160
140 140 140 140
120 120 120 120
100 100 100 100
No.

No.

No.

No.
80 80 80 80
60 60 60 60
40 40 40 40
20 20 20 20
0 0 0 0
20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20
10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19
(e) fs (f) include (g) ipc (h) kernel
160 160 160 160
140 140 140 140
120 120 120 120
100 100 100 100
No.

No.

No.

No.
80 80 80 80
60 60 60 60
40 40 40 40
20 20 20 20
0 0 0 0
20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20
10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19
(i) lib (j) mm (k) net (l) security

160 160 160 160

140 140 140 140
120 120 120 120
100 100 100 100
No.

No.

No.

No.
80 80 80 80
60 60 60 60
40 40 40 40
20 20 20 20
0 0 0 0
20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20
10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19
(m) sound (n) tools (o) virt (p) proc

160 160
140 140
120 120
100 100
No.

No.

80 80
60 60
40 40
20 20
0 0
20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20
10

11

12

13

14

15

16

17

18

19

10

11

12

13

14

15

16

17

18

19

(q) dev (r) other

Fig. 6: The state of growth or decrease of vulnerability detection for each Linux Kernel component over the last ten years

capabilities. In contrast, for high privilege level, the attacker used to assign a score to a vulnerability by taking into
must have administrative access, capable of changing set- account unique characteristics of the given vulnerability
tings and files in the kernel. As seen in Figure 13, for 68% of such as the impact and complexity of the attack. The higher
the vulnerabilities (None permission), the attacker does not the score, the more dangerous the vulnerability is.
need any access to settings or files to carry out an attack. There are three metric groups in CVSS, namely base,
For 31% of the vulnerabilities (Low permission), the temporal, and environmental metrics that can affect the
normal user power is needed. Only for 14 vulnerabilities, results of CVSS score. The score is always a number from
the attacker needs the high privileges to exploit the vulner- 0 to 10 and must be accompanied by a CVSS vector. The
ability successfully. base metrics are the core of the CVSS. Their metrics are not
subject to change over time. Moreover, they do not depend
3.7 Attack Severity Level on the user’s environment. The current version of CVSS is
The vulnerability score in NVD Dataset is calculated using version three. Note that in the NVD dataset, the scoring
the CVSS [8], [18], which is an open vulnerability framework value is available with both the second and third versions
 8

260 260 260

240 240 240
220 220 220
200 200 200
180 180 180
160 160 160
140 140 140
No.

No.

No.
120 120 120
100 100 100
80 80 80
60 60 60
40 40 40
20 20 20
0 0 0
1.* 2.* 3.* 4.* 5.* 1.* 2.* 3.* 4.* 5.* 1.* 2.* 3.* 4.* 5.*

(a) Information Leak (b) Input Validation (c) Access Control

260 260 260
240 240 240
220 220 220
200 200 200
180 180 180
160 160 160
140 140 140
No.

No.

No.
120 120 120
100 100 100
80 80 80
60 60 60
40 40 40
20 20 20
0 0 0
1.* 2.* 3.* 4.* 5.* 1.* 2.* 3.* 4.* 5.* 1.* 2.* 3.* 4.* 5.*

(d) Resource Management (e) Buffer Errors (f) Numeric Errors

260 260 260
240 240 240
220 220 220
200 200 200
180 180 180
160 160 160
140 140 140
No.

No.

No.
120 120 120
100 100 100
80 80 80
60 60 60
40 40 40
20 20 20
0 0 0
1.* 2.* 3.* 4.* 5.* 1.* 2.* 3.* 4.* 5.* 1.* 2.* 3.* 4.* 5.*

(g) Race Conditions (h) Out-of-bounds Write (i) Use After Free
260 260 260
240 240 240
220 220 220
200 200 200
180 180 180
160 160 160
140 140 140
No.

No.

No.

120 120 120

100 100 100
80 80 80
60 60 60
40 40 40
20 20 20
0 0 0
1.* 2.* 3.* 4.* 5.* 1.* 2.* 3.* 4.* 5.* 1.* 2.* 3.* 4.* 5.*

(j) NULL Pointer Dereference (k) Out-of-bounds Read (l) Uncontrolled Resource Consumption

Fig. 7: The relationship between the vulnerabilities discovered in each vulnerability type and kernel versions

of the CVSS, but there is no guarantee about Version 3 result separate user in the successful compromise of the
for all vulnerabilities. CVSS v3 has introduced a lot of en- vulnerable target.
hancements [24], which addressed some of the shortcomings • Scope (S): reflects this fact that whether the attacker
of CVSS Version 2 [9], [12]. In the following, the base group can impact other resources from the compromised
metrics of Version 3 are explained: resource.
• Confidentiality Impact (C): measures the impact to
• Access Vector (AV): reflects how the vulnerability is
the confidentiality of the information.
exploited.
• Integrity Impact (I): measures the impact to the in-
• Access Complexity (AC): reflects the obstacles be-
tegrity of the information.
yond the attacker’s control and needed to be by-
• Availability Impact (A): measures the impact to the
passed for the attack to be successful.
availability of the information.
• Privileges Required (PR): reflects the level of privi-
leges an attacker must have to exploit the target. Table 2 summarizes metrics and their values used in
• User Interaction (UI): reflects the contribution of a CVSS Version 3 formulation. The base score function is
 9

1600 1508
800 779
1400

Number of Vulnerabilities
Confidentiality−Low
700
Number of Vulnerabilities
Confidentiality−High
1200 600
500
1000
400
800 300
200 156
600 100 97
27 7 15 37
2
400 350 0

Lo

Ad

Ph
et
ca

ja

ys
w

ce
200

ic
or

al
n
k

t−
ne
0

tw
or
Lo

k
ig
w

h
(a) Confidentiality
Linux Kernel Components
700
Fig. 9: Vulnerability distribution by attack complexity

Number of Vulnerabilities
Integrity−Low
600 Integrity−High
526
500

1200 400
Number of Vulnerabilities

1103
1100 Low 300
1000 High
900 200
800 100 62
700 23 45 2 8 0 27
600 0

Lo

Ad

Ph
500

et
c

ja

ys
w
al
400

ce

ic
or
302 282

al
nt
k
300

− ne
200

tw
80

or
100 34 43 12

k
2
0 (b) Integrity
Lo

Ad

Ph
et
ca

ja

ys
w

ce
l

i
or

ca
nt
k

l
−

1100
ne

1024
Number of Vulnerabilities
t

Availability−Low
w

1000
or
k

900 Availability−High
800
Fig. 10: Origin of attack versus attack complexity 700
600
Linux Kernel Components 500
400
evaluated as follows: 300 247
200
100 57 75
26 3 43 0
 0
0 if Is ≤ 0
Lo

Ad

Ph

et
c

ja

ys
w
al

Bs= Roundup(M in[(Is + Es ), 10]) if S = U nchanged (1)

ic
or

en

al
k

t−

Roundup(M in[1.08 × (I + E ), 10]) if S = Changed
s s

ne
tw
or
k
where Is and Es are impact and exploitability sub scores, (c) Availability
respectively. Is is defined as follows:
Fig. 12: Origin of attack versus impact
(
6.42 × Ib if S = U nchanged
Is= (2)
7.52 × [Ib − 0.029] − 3.25 × [Ib − 0.02]15 if S = Changed

where
1263
1200
1050
Number of Vulnerabilities

1400 1389
Low
Number of Vulnerabilities

1200 900
High
1000 928 750
800 724 600 581

600 450
400 300
200 192
98 86 150
0 14
0
C

In

Av
on

te

Lo

H
ai
g
fid

on

ig
la
rit

h
bi
en

e
y

lit
tia

y
lit

Fig. 13: Vulnerability distribution by privileges

y

Fig. 11: Vulnerability distribution by impact

 10

TABLE 2: Summary description of CVSS v3 base metrics and Buffer errors vulnerabilities (CWE-119) constitute for
their values 10.5% (195/1,858) of all the vulnerabilities. The vulnera-
bilities in this category may lead to code that can read
Metric ID Metric Value
from or write to a memory location that is outside of the
Access Vector AV Network-Adjacent intended boundary of the buffer. There are no known ways
Local-Physical to completely prevent buffer errors at either software or
Attack Complexity AC Low-High hardware levels. Most widely proposed solutions suffer
Privileges Required PR None-Low-High
User Interaction UI None-Required from memory overheads (e.g., stack cookie or stack canary
Scope S Unchanged-Required solutions).
Confidentiality Impact C None-Low-Medium-High Access control (CWE-264) vulnerability allows an at-
Integrity Impact I None-Low-Medium-High
tacker to gain a privileged path to important system assets
Availability Impact A None-Low-Medium-High
usually by bypassing permissions or privileges. Attackers
exploit this type of vulnerability typically to disclose sen-
700 682 sitive information, modify files, or initiate other possible
650 attacks. About 9% (169/1,858) vulnerabilities are related
600
to this type. Many parts of the Linux kernel should be
Number of Vulnerabilities

550
500 improved to mitigate this type of attack, including 1) root
450 412 account, 2) user authentication and user account attributes,
400
3) remote authentication, 4) file system, 5) services config-
350 323
300 uration. There are several solutions to improve the secu-
250 rity of Linux that is related to path management. Existing
200 177 tools (e.g., up2date, YaST, apt-get), which can automatically
150
100 82 download and install security updates, should be used to
58 68
50 33 23 provide patches. For network access control, TCP Wrappers
0
0 is a key tool. It is a host-based networking ACL system to
0−

1−

2−

3−

4−

5−

6−

7−

8−

9−

restrict access to network services running on a Linux server

1

10

[33].
Fig. 14: Vulnerability distribution by CVSS score Input validation (CWE-20) vulnerability refers to im-
proper validation of input data that can affect the control
flow or data flow of a program. About 8.3% (169/1,858)
vulnerabilities are related to this type. This attack can occur
in a wide range of Linux modules, such as USB, driver (e.g.,
Ib= 1 − [(1 − C) × (1 − I) × (1 − A)] (3) network card), many functions in the libraries. To mitigate
this vulnerability, the corresponding functions should be
and the Exploitability sub-score (Es ) is defined as fol-
corrected.
lows:
About 6.8% (128/1,858) vulnerabilities are related to
resource management vulnerability type (CWE-399). This
vulnerability refers to improper management of system
Es= 8.22 × AV × AC × P R × U I (4)
resources. This vulnerability can happen in many parts of
Linux, like memory leak in the gpu driver, file system NFSv4
Figure 14 shows the scoring results for the 1,858 vulner-
implementation, tcp connection in network, socket imple-
abilities. As we see, about 36.7% of the vulnerabilities lie in
mentation, and etc. There is no comprehensive solution for
range 7 to 8. The second place belongs to range 4 to 5, which
all vulnerabilities in this type and should be addressed case
is about 22% of the total vulnerabilities. The CVSS score
per case.
shows that about 3.6% of vulnerabilities are very dangerous.
About 5.7% (107/1,858) vulnerabilities are related to type
Use-After-Free (CWE-416). Use after free errors occur when
a program continues to use a pointer after it has been freed
4 D ISCUSSION AND I MPLICATIONS
[29]. Kernel Address Sanitizer (KASAN) is a commercial
In this section, we discuss the main important vulnerability solution to mitigate Use-After-Free type. KASAN is GCC
types, the research, and commercial solutions to mitigate plugin that tracks dynamic memory allocations in Kernel us-
them. ing compiler instrumentation techniques to prevent pointers
Information leak (CWE-200) is the intentional or unin- to invalid memory regions [25]. Note that KASAN suffers
tentional disclosure of authorized information to an actor. performance and memory overhead [26]. Several research
About 13% (240/1,858) vulnerabilities are related to this studies have been conducted to tackle this vulnerability
type. This weakness could be a result of problems that type [26]–[29]. For example, in [28], Lee et al. proposed a
involve exposure of sensitive information [34]. It can happen solution to automatically trace the object’s relationships via
in many situations such as sending data, caching, indexing pointers and automatically nullifies all pointers when the
of private data, etc. There is no specific solution for this type target object is freed.
of vulnerability. We should prevent allowing sensitive data NULL pointer dereference vulnerability type (CWE-476)
to go outside of the trust boundary when interfacing with a is a result of NULL pointers being dereferenced before null-
compartment outside of the safe area. check in the kernel. About 5.6% (105/1,858) vulnerabilities
 11

are related to this type. Smatch [30] and Coccinelle [31] are these vulnerabilities that have high impact can be
two tools that can find NULL deference bugs by analyzing locally exploited, which further justifies the need for
the source code. However, these tools have limitations, for host-based detection techniques.
example, they are commonly restricted to intra-procedural • The majority of attacks do not need any privilege to
analysis of isolated functions and cannot manage nested exploit the target.
function calls [32]. • For complex attacks, such as Drovorub [11] (Re-
About 5.5% (103/1,858) vulnerabilities are related to race ported in 2020) which hides itself and the implant
condition vulnerability type (CWE-362). This vulnerability on infected devices, the only mitigation solution is to
refers to poor management when multiple processes access update Linux kernel to the new version.
and manipulate the same data concurrently. This vulnera-
bility is one of the hardest ones to diagnose and fix. We did 6 C ONCLUSION
not find many studies that address this type of vulnerability. The Common Vulnerabilities and exposures (CVE) system
To our knowledge the few studies that exist (e.g., [35]) are represents a reference method for publicly known security
limited to file accesses. vulnerabilities for a wide range of products. NVD (National
Numeric errors vulnerability type (CWE-189) covers Vulnerability Database) provides a database which is fully
about 4.3% (81/1,858) of all the vulnerabilities. It is related to synchronized with the CVE List. The total number of entries
improper calculation or conversion of numbers. This type of in CVE is 83,616 since 2010 to 2020. Therefore, to confront
vulnerability also exists in a variety of Linux modules. Sim- cyber attacks, these vulnerabilities must be investigated
ilar to buffer errors and resource management vulnerability precisely. Linux operating system, as one of the most widely
types, there are no known ways to completely mitigate this used operating systems, consists of several components.
type. A comprehensive analysis of the vulnerabilities of those
components is significantly momentous.
5 C ONCLUSION OF S TATISTICS A total of 1,858 vulnerabilities over past ten years were
In this paper, we analyzed 1,858 vulnerabilities of the Linux extracted from NVD for Linux kernel. Seven criteria were
kernel from 2010 to 2020 reported on the NVD. Our conclu- proposed to anylayze these vulnerabilities, which are: ob-
sion of statistics along with recommendations are: jective of attack, affected Linux kernel components, origin
of attack, complexity of attack, impact of attack, attack
• Information leak (impact is on C), improper input privilege, and severity level of attack. These criteria most
validation(impact is on CIA), permissions, privileges, adequately reflect how attackers would use vulnerabilities
and access Controls (impact is on CIA), resource to cause exploits. The key findings are summarized as
management errors (impact is on A), buffer errors follows: 1) The kernel has a large number of low-complexity
(impact is on CIA), numeric errors (impact is on vulnerabilities that can be easily exploited from the local
A), and race conditions (impact is on CIA) are the system (i.e., without the need for remote access location), 2)
main objectives of attack. As seen, the impact on A large number of vulnerabilities can be exploited to cause
availability criterion is common among these seven denial of service, 3) Vulnerabilities that permit bypassing
main categories. This suggests that the techniques security restrictions and gaining elevated privileges are also
which ensure high-availability of services of Linux- a common threat.
based systems should be consider as the main job by
security experts.
R EFERENCES
• The arch, net, fs, and drivers subsystems of the kernel
are most frequently reported vulnerable and hence [1] Ahmed M, Mahmood AN, Hu J. A survey of network anomaly
detection techniques. Journal of Network and Computer Applica-
the likely target of exploits. These components re- tions. 2016 Jan 1;60:19-31.
quire special attention from developers and security [2] Bagherzadeh M, Kahani N, Bezemer CP, Hassan AE, Dingel J,
testers. Also, host-based detection techniques should Cordy JR. Analyzing a decade of Linux system calls. Empirical
Software Engineering. 2018 Jun 1;23(3):1519-51.
put an emphasis on acute monitoring of these com- [3] Wang P, Krinke J, Lu K, Li G, Dodier-Lazaro S. How double-fetch
ponents. situations turn into double-fetch vulnerabilities: A study of double
• Majority of the vulnerabilities are locally exploitable. fetches in the Linux kernel. InUSENIX Security Symposium 2017
Thus host-based intrusion detection systems should Aug 16.
[4] Xu W, Li J, Shu J, Yang W, Xie T, Zhang Y, Gu D. From collision
be given attention in conjunction with network- to exploitation: Unleashing use-after-free vulnerabilities in linux
based intrusion detection systems for attack preven- kernel. In Proceedings of the 22nd ACM SIGSAC Conference on
tion. Computer and Communications Security 2015 Oct 12 (pp. 414-425).
ACM.
• Exploiting vulnerabilities in 1,508 out 1,858 cases is
[5] Gens D, Schmitt S, Davi L, Sadeghi AR. K-miner: Uncovering
of low complexity, making it easy for attackers with memory corruption in linux. In Proceedings of the 2018 Annual
basic skills to attack the kernel. More emphasis must Network and Distributed System Security Symposium (NDSS), San
thus be placed on security during kernel design, to Diego, CA 2018 Feb.
[6] National Vulnerability Database URL: http://nvd.nist.gov
proactively address such vulnerabilities. Addition- [7] D. Ghosh, R. Sharman, H. R. Rao, S. Upadhyaya , ”Self-healing
ally, most of these low complexity attacks are locally systems -survey and synthesis,” In the Journal of Decision Support
exploitable, further emphasizing the importance of Systems, 42(4), 2007
host-based intrusion detection systems. [8] Allodi, L., Banescu, S., Femmer, H., & Beckers, K. (2018, March).
Identifying Relevant Information Cues for Vulnerability Assess-
• A large number of vulnerabilities have high impact ment Using CVSS. In Proceedings of the Eighth ACM Conference
on confidentiality, integrity, and availability. Most of on Data and Application Security and Privacy (pp. 119-126). ACM.
 12

[9] Mell, P., Scarfone, K., & Romanosky, S. (2007, June). A complete [33] G. Canepa, ”How to Secure Network Services Using TCP Wrap-
guide to the common vulnerability scoring system version 2.0. pers in Linux,” 2016.
In Published by FIRST-Forum of Incident Response and Security [34] T. Dang and D. Wagner, ”The Performance Cost of Shadow Stacks
Teams (Vol. 1, p. 23). and Stack Canaries,” pp. 1-12.
[10] Santos, O. (2016, October). The Evolution of Scoring Security [35] E. Tsyrklevich and B. Yee, ”Dynamic detection and prevention of
Vulnerabilities: The Sequel. race conditions in file accesses,” PhD diss., University of California,
[11] National Security Agency (NSA) and Federal Bureau of Investi- San Diego, 2003.
gation (FBI). Russian GRU 85th GTsSS Deploys Previously Undis-
closed Drovorub Malware. August 2020 Rev 1.0.
[12] Eiram, C., & Martin, B. (2013). The CVSSv2 shortcomings, faults,
and failures formulation. In Technical report, Forum of Incident
Response and Security Teams (FIRST).
[13] Zhou M, Chen Q, Mockus A, Wu F. On the scalability of Linux
kernel maintainers’ work. In Proceedings of the 2017 11th Joint Alireza Shameli-Sendi is currently an Assistant
Meeting on Foundations of Software Engineering 2017 Aug 21 (pp. Professor at Shahid Beheshti University. Before
27-37). ACM. joining SBU, he was a Postdoctoral Fellow at
[14] C. Simmons, C. Ellis, S. Shiva, D. Dasgupta, Q.Wu. “AVOIDIT: A Ericsson, Canada and Postdoctoral at ETS and
Cyber Attack Taxonomy,” Technical Report: CS-09-003, University McGill universities in collaboration with Ericsson.
of Memphis, 2009. He received his Ph.D degree in computer en-
[15] D.Lough. ‘A Taxonomy of Computer Attacks with Applications to gineering from Montreal University (Ecole Poly-
Wireless Networks’, PhD Thesis Dissertation, Virginia Polytechnic technique de Montreal), Canada. He obtained
Institute and State University, 2001. his B.Sc. and M.Sc. from Amirkabir University
[16] H. Chen, Y. Mao, X. Wang, D. Zhou, N. Zeldovich, M. Frans of Technology. His primary research interests
Kaashoek, “Linux kernel vulnerabilities: State-of-the-art defenses include information security, intrusion response
and open problems,” In Proc. of the Second Asia-Pacific Workshop system, and cloud computing. He is a recipient of Postdoctoral Research
on Systems, 2011. Fellowship Award and Industrial Postdoctoral Fellowship Award from
[17] S. Mokhov, M. Laverdière, D. Benredjem, “Taxonomy of Linux Canada. In addition, he received the best researcher award, in industrial
Kernel Vulnerability Solutions,” In Proc. of the International Joint track, at SBU, in 2018.
Conferences on Computer, Information, and Systems Sciences, and
Engineering, 2007.
[18] P. Mell, K. Scarfone, S. Romanosky, “A Complete Guide to
the Common Vulnerability Scoring System version 2.0,” URL:
http://www.first.org/cvss/cvss-guide.html.
[19] G. Alvarez and S. Petrovic, “A new taxonomy of web attacks
suitable for efficient encoding,” Elsevier Journal on Computers and
Security, 22(5):435–449, 2003.
[20] M. Bishop, “A taxonomy of Unix and network security vul-
nerabilities,” Technical report, Department of Computer Science,
University of California at Davis, 1995.
[21] J. D. Howard and T. A. Longstaff, “A common language for com-
puter security incidents,” Technical Report SAND 988667, Sandia
National Laboratories, Albuquerque, New Mexico and Livermore,
California, 1998.
[22] C. E. Landwehr, A. R. Bull, J. P. McDermott, and W. S. Choi, “A
taxonomy of computer program security flaws, with examples,”
ACM Computing Surveys, 26(3):211–254, 1994.
[23] P. Argyroudis, D. Glynos, “Protecting the Core Kernel Exploitation
Mitigations,” Black Hat Europe, 2011.
[24] Santos, O. (2016, October). The Evolution of Scoring Security
Vulnerabilities: The Sequel.
[25] KASAN, The Kernel Address Sanitizer (KASAN),
www.kernel.org/doc/html/v4.10/dev-tools/kasan.html, 2017.
[26] W. Wu, Y. Chen, J. Xu, X. Xing, X. Gong, and W. Zou, ”FUZE:
Towards Facilitating Exploit Generation for Kernel Use-After-Free
Vulnerabilities,” In 27th USENIX Security Symposium (USENIX
Security 18), pp. 781-797, 2018.
[27] J. Caballero, G. Grieco, M. Marron, and A. Nappa, ”Undangle:
early detection of dangling pointers in use-after-free and double-
free vulnerabilities,” In Proceedings of the 2012 International Sym-
posium on Software Testing and Analysis, pp. 133-143. ACM, 2012.
[28] B. Lee, C. Song, Y. Jang, T. Wang, T. Kim, L. Lu, and W. Lee,
”Preventing Use-after-free with Dangling Pointers Nullification,”
In NDSS, 2015.
[29] W. Xu, J. Li, J. Shu, W. Yang, T. Xie, Y. Zhang, and D. Gu, ”From
collision to exploitation: Unleashing use-after-free vulnerabilities in
linux kernel,” In Proceedings of the 22nd ACM SIGSAC Conference
on Computer and Communications Security, pp. 414-425. ACM,
2015.
[30] Smatch the source matcher. http://smatch.sourceforge.net/. (Ac-
cessed on 30/03/2021).
[31] Coccinelle: A program matching and transformation tool for sys-
tems code. http: //coccinelle.lip6.fr/. (Accessed on 30/03/2021).
[32] I. Abal, C. Brabrand, and A. Wasowski, ”Effective bug finding in
c programs with shape and effect abstractions,” In International
Conference on Verification, Model Checking, and Abstract Inter-
pretation, pp. 34-54. Springer, Cham, 2017.