Another null pointer exploit

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:

    static int
    pipe_write_open(struct inode *inode, struct file *filp)
    {
	mutex_lock(&inode->i_mutex);
	inode->i_pipe->writers++;
	mutex_unlock(&inode->i_mutex);

	return 0;
    }

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.

The fix 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.