Kernel Stack Overflows Elimination - Advanced Operating Systems and Kernel Applications - page 6

Memory corruption caused by a stack overflow
may cause the system to be in an undefined state
(Wilander and Kamkar, 2003). The kernel makes
no effort to manage the stack and no essential
mechanism oversees the stack size.
In (Chou et al., 2001) the authors present an
empirical study of Linux bugs. The study com-
pares errors in different subsections of Linux
kernels, discovers how bugs are distributed and
generated, calculates how long, on average, bugs
live, clusters bugs according to error types, and
compares the Linux kernel bugs to the OpenBSD
kernel bugs. The data used in this study was col-
lected from snapshots of the Linux kernel across
seven years. The study refers to the versions
until the 2.4.1 kernel series, as it was published
in 2001. 1025 bugs were reported in this study.
The reason for 102 of these bugs is large stack
variables on the fixed-size kernel stack. Most of
the fixed-size stack overflow bugs are located in
device drivers. Device drivers are written by many
developers who may understand the device more
than the kernel, but are not aware of the kernel
stack limitation. Hence, no attempt is made to
confront this setback. In addition, only a few users
may have a given device; thus, only a minimal
check might be made for some device drivers. In
addition, Cut-and-Paste bugs are very common
in device drivers and elsewhere (Li et al., 2004);
therefore, the stack overflow bugs are incessantly
and unwarily spread.
The goal of malicious attackers is to drive
the system into an unexpected state, which can
help the attacker to infiltrate into the protected
portion of the operating system. Overflowing
the kernel stack can provide the attacker this
option which can have very devastating security
implications (Coverity, 2004). The attackers look
for rare failure cases that almost never happen in
normal system operations. It is hard to track down
all the rare cases of kernel stack overflow, thus
the operating system remains vulnerable. This
leads us to the unavoidable conclusion: Since
the stack overflows are difficult to detect and fix,

the necessary solution is letting the kernel stack
grow dynamically.
A small fixed size stack is a liability when
trying to port code from other systems to Linux.
The kernel thread capability would seem offer
an ideal platform for porting user code and non-
Linux OS code. This facility is limited both by
the lack of a per-process memory space and by a
small fixed sized size stack.
An example of the inadequacy of the fixed size
stack is in the very popular use of the Ndiswrapper
project (Fuchs and Pemmasani, 2005) to imple-
ment Windows kernel API and NDIS (Network
Driver Interface Specification) API within the
Linux kernel. This can allow the use of a Windows
binary driver for a wireless network card running
natively within the Linux kernel, without binary
emulation. This is frequently the solution used
when hardware manufacturers refuse to release
detail of their product so a native Linux driver is
not available.
The problem with this approach is that the
Windows kernel provides a minimum of 12KB
kernel stack whereas Linux in the best case uses
an 8KB stack. This mismatch of kernel stack
sizes can and cause system stack corruptions
leading to kernel crashes. This would ironically
seem to be the ultimate revenge of an OS (MS
Windows) not known for long term reliability on
an OS (Linux) which normally is known for its
long term stability.

current Solutions

Currently, Operating Systems developers have
suggested several methods how to tackle the kernel
stack overflows. They suggest to change the way
of writing the code that supposed to be executed
in kernel mode instead of changing the way that
kernel stack is handled. This is unacceptable - the
system must cater for its users!
The common guidance for kernel code devel-
opers is not to write recursive functions. Infinite
number of calls to a recursive function is a com-