Over the last month, there have been eleven separate releases in the 2.6.16
stable kernel series, seven of which were single-patch releases for security
related issues. This flurry of security fixes would make one think that
there was a concerted effort by an individual or organization to try and
find kernel security problems, but that is not the case. It is entirely
coincidental that all of these fixes came about at around the same time.
A chronological look at each of these fixes gives a nice picture of the
diverse places that kernel developers are looking for bugs in general
and security bugs in particular.
Roughly a week after the original 2.6.16 release, the 188.8.131.52 release
contained 19 patches, including one that fixed
Code had been put into the kernel in the 2.4 series to stop leaking
information in the form of fragment IDs in TCP packets that did not
require them. Packets that have the DF (don't fragment) bit set do
not need a fragment ID and eliminating that information is a
countermeasure to a technique called
Unfortunately when the original change was made, the response to a
certain kind of packet (a SYN-ACK packet) was missed and that was
discovered in March.
The 184.108.40.206 release came out on 7 April and had a quite a few
fixes including a change
to the sysfs interface covered
by LWN two weeks ago.
On the 11th and 12th of April, there were 3 releases, each of which
included just one security fix. 220.127.116.11 is a fix for a bug that would
allow a user to oops the kernel by passing invalid arguments to the keyctl
If the user specified a key as the target for an "add key" operation,
rather than a keyring, a invalid dereference in the kernel would result.
A call to BUG_ON() in the __group_complete_signal() function
(which is part of the RCU signal handling code)
"has unknown impact and attack vectors" and was patched as 18.104.22.168. If a
user process could cause the condition in the BUG_ON call, it could
oops the kernel and lead to a denial of service.
A difference in the way Intel and AMD 64-bit CPUs handle non-canonical return
addresses led to the 22.214.171.124 release. The Intel CPU reports the exception
on the SYSRET instruction which causes the kernel exception handler
to run using the user stack.
Kernel processing using a user created stack would seem rife with opportunities
The 126.96.36.199 release came out a week later with another long
list of patches, two of which
have security implications. The m32r architecture had a bug in the
get_user and put_user macros that did not check the
address passed to them which would allow access outside of the process
A more widespread issue was addressed with a patch in this
release and then fixed in the 188.8.131.52 release later in the day.
The MADV_REMOVE vulnerability
(CVE-2006-1524) has been present in kernels since 2.4 and allows local users
to potentially bypass the access restrictions on a read-only attachment
of shared memory. The user process could call mprotect() and gain
write permission on a piece of memory even though the memory was
explicitly set to be read-only when shared via the shared memory IPC
Prior to 184.108.40.206, the kernel was vulnerable to users causing a kernel panic
by requesting a route for a multicast IP address
(CVE-2006-1525). Using a simple 'ip' command from the shell would cause a
null pointer dereference in ip_route_input and panic the kernel.
This is another example of a local denial of service vulnerability.
220.127.116.11 patches a problem that affected both Linux and FreeBSD kernels
running on AMD processors which would allow a malicious process running on
the same CPU to determine portions of the state of floating point
instructions in a target process. AMD had some
comments on the bug and
provided some background information on why they chose to implement the
FXRSTOR and FXSAVE instructions differently than they
are implemented in Intel processors. Essentially, these two instructions
do not save and restore all of the same registers as Intel does and this
allows information to leak from one process to another. The patch ensures
that the floating point state is constant between context switches on
Last on our tour of kernel security fixes is a patch made in 18.104.22.168
and released on Monday that
disallows backslashes in path components unless POSIX paths have been
negotiated. This change is for the CIFS (aka Samba) filesystem code;
one can only imagine the kinds of havoc one could cause by putting
backslashes (the standard Windows path separator) into CIFS paths.
This bug is
but the CVE database just shows a placeholder page for that
number at the time of this writing.
Observant readers will have noticed that
we skipped over 22.214.171.124 as it was a release with quite a few patches, none
of which were noted as being security related.
As this laundry list of issues shows, there are a wide variety of places
that kernel bugs can impact security, but the many eyes of kernel developers
seem to be finding and fixing them. This process plays out in the open
and that can give competitors ammunition to claim that Linux is less
secure than certain proprietary systems. Reasonable people
would more likely come to the conclusion that Linux developers are much more
interested in finding these issues and fixing them. The kernel
community has no interest in hiding vulnerabilities or playing games
with security patch descriptions to make the OS look more secure. PR
considerations just do not seem to be on the radar of the technical
contributors and that is just as it should be.
to post comments)