A flurry of kernel security fixes

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 2.6.16.1 release contained 19 patches, including one that fixed CVE-2006-1242. 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 idle scanning. 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 2.6.16.2 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. 2.6.16.3 is a fix for a bug that would allow a user to oops the kernel by passing invalid arguments to the keyctl utility (CVE-2006-1522). 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 2.6.16.4. 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. (CVE-2006-1523).

A difference in the way Intel and AMD 64-bit CPUs handle non-canonical return addresses led to the 2.6.16.5 release. The Intel CPU reports the exception on the SYSRET instruction which causes the kernel exception handler to run using the user stack. (CVE-2006-0744). Kernel processing using a user created stack would seem rife with opportunities for exploitation.

The 2.6.16.6 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 address space.

A more widespread issue was addressed with a patch in this release and then fixed in the 2.6.16.7 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 mechanism.

Prior to 2.6.16.8, 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.

2.6.16.9 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 affected processors. (CVE-2006-1056)

Last on our tour of kernel security fixes is a patch made in 2.6.16.11 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 CVE-2006-1863, 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 2.6.16.10 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.