What you're missing is that the pipe_open function shown above isn't the area of code that directly makes the vulnerability exploitable for arbitrary code execution. Your analysis of that particular function is correct, but the pipe_open function is only needed to get a file descriptor that pipe_read, pipe_write, or others can then be used on. It's these functions that make the vulnerability exploitable.
Take a look at the exploit linked to above; I've commented it sufficiently that you should be able to see exactly how the vulnerability is exploited for privilege escalation.
For 2.6.10+ kernels, the attacker by correctly filling out the pipe_inode_info struct can pass through some checks and cause the kernel to make use of an attacker-supplied pointer to an array of function pointers -- the values of which are also supplied by the attacker (to the code that compromises the kernel). For 2.4 and 2.6.9 and below, the array of function pointers doesn't exist, but an attacker-controlled pointer that determines the location in the kernel to be written to by the pipe will allow for overwriting of a function pointer in the kernel and then subsequently arbitrary code execution.