Potential risk in xt_socket match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, All

When I read net/netfilter/xt_socket.c, I found maybe there will be a
potential risk in this match.

Linux-3.4.4
socket_match(...)
{
    ...snip...
    sk = nf_tproxy_get_sock_v4(...);
    if (sk != NULL) {
          do_some_check();
          xt_socket_put_sk(sk);
          if (wildcard || !transparent)
               sk = NULL;
    }
    pr_debug(...);
    return sk != NULL;
}

Assuming that, we got the tproxyed socket by nf_tproxy_get_sock_v4()
and we should do some more check for it. Before we call
do_some_check(), xt_socket give up CPU to let other process run. In
this period, sk maybe updated. This is common for SMP CPU. Other CPU
maybe try to destroy the sk structure if socket process is killed or
even socket APP crashed. The sk structure will not be  really freed,
because we hold the ref of the sk, but maybe some structure members is
cleaned up.

When xt_socket match run again, sk members are changed.

So, should we use socket lock which is similar to tcp_v4_rcv() to
protect the sk structure we got by nf_tproxy_get_sock_v4()?

Like this:
    if (sk != NULL) {
          bh_lock_sock_nested(sk);
          do_some_check();
          bh_unlock_sock(sk);
          xt_socket_put_sk(sk);
          if (wildcard || !transparent)
               sk = NULL;
    }

Anyone have idea about this issue?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux