Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fixed explanation of tun->sk NCE

...

Code Block
bgColor#FFCCCC
langc
static unsigned int tun_chr_poll(struct file *file, poll_table * wait)  {
  struct tun_file *tfile = file->private_data;
  struct tun_struct *tun = __tun_get(tfile);
  struct sock *sk = tun->sk;
  unsigned int mask = 0;

  if (!tun)
    return POLLERR;

  DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);

  poll_wait(file, &tun->socket.wait, wait);

  if (!skb_queue_empty(&tun->readq))
    mask |= POLLIN | POLLRDNORM;

  if (sock_writeable(sk) ||
     (!test_and_set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags) &&
     sock_writeable(sk)))
    mask |= POLLOUT | POLLWRNORM;

  if (tun->dev->reg_state != NETREG_REGISTERED)
    mask = POLLERR;

  tun_put(tun);
  return mask;
}

The vulnerability occurs because sk pointer is initialized to tun->sk before checking if tun is a null pointer. The   Because null pointer dereferencing is undefined behavior, the compiler (GCC in this case) optimizes can optimize away the if (!tun) check because it is performed after the assignment tun->sk is dereferenced, implying that tun is non-null. As a result, this noncompliant code example is vulnerable to a null pointer dereference exploit.  Typically, a null pointer dereference results in access violation and abnormal program termination. However, it is possible to permit null pointer dereferencing on several operating systems, for example, using mmap(2) with the MAP_FIXED flag on Linux and Mac OS X or using shmat(2) with the SHM_RND flag on Linux [Liu 2009].

...