Back in mid-October, Earl Chew
null pointer crash in the kernel pipe code. Initial response to his report
was somewhat slow, partly because the kernel he was running was based on
2.6.21. Earl took the time to dig through the code and identify the
problem, though; it turns out to be an old vulnerability which is still
present in current kernels.
What it comes down to is that there is a race condition in the pipe code.
Prior to 2.6.32-rc6, the code which opens a pipe (for write-only access, in
this case) looks like:
pipe_write_open(struct inode *inode, struct file *filp)
The problem is that if the final close of this pipe slips in at the wrong
time, inode->i_pipe may have been set to null. So this is yet
another null pointer vulnerability; the rest is just a matter of writing
the exploit. That exploit must face the challenge that the window of
opportunity is quite short, but computers are very good at continually
trying things until something works.
makes the code much more careful about checking the current status of the
pipe and refusing new opens if the final close has already happened.
Distributors are shipping updates.
This particular bug is attracting attention because it is in the core
kernel and (relatively) straightforward to trigger. But it is far from
unique. A quick look at commits since 2.6.31 turns up no fewer than 34
which explicitly fix null pointer dereference bugs. Quite a few more fix
things that could be null pointer bugs, and there's no telling how many
more were fixed without an explicit mention in the commit title. Null
pointer bugs are common, and are likely to remain so for quite some time.
What is surprising about this bug is that some distributions are still
vulnerable to it. We have had the ability to keep null pointer bugs from
being exploitable for some time, but certain distributions - generally of
the "enterprise" variety - disable that protection by default. Sites
running such distributions might want to be sure that they have the
vm.mmap_min_addr knob set to a reasonable value; either that or expect to
be vulnerable to more null pointer exploits in the future.
to post comments)