diff options
| author |   Eric Dumazet <edumazet@google.com> | 2015-03-11 18:53:14 -0700 |
|---|---|---|
| committer |   David S. Miller <davem@davemloft.net> | 2015-03-11 21:55:28 -0400 |
| commit | 33cf7c90fe2f97afb1cadaa0cfb782cb9d1b9ee2 (patch) | |
| tree | 7a0c80d0b2bb618919d966ce5b827c7eb8f843f6 /net/ipv4/syncookies.c | |
| parent | fib_trie: Only display main table in /proc/net/route (diff) | |
| download | linux-dev-33cf7c90fe2f97afb1cadaa0cfb782cb9d1b9ee2.tar.xz linux-dev-33cf7c90fe2f97afb1cadaa0cfb782cb9d1b9ee2.zip | |
net: add real socket cookies
A long standing problem in netlink socket dumps is the use
of kernel socket addresses as cookies.
1) It is a security concern.
2) Sockets can be reused quite quickly, so there is
no guarantee a cookie is used once and identify
a flow.
3) request sock, establish sock, and timewait socks
for a given flow have different cookies.
Part of our effort to bring better TCP statistics requires
to switch to a different allocator.
In this patch, I chose to use a per network namespace 64bit generator,
and to use it only in the case a socket needs to be dumped to netlink.
(This might be refined later if needed)
Note that I tried to carry cookies from request sock, to establish sock,
then timewait sockets.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Eric Salo <salo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/syncookies.c')
| -rw-r--r-- | net/ipv4/syncookies.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c index 45fe60c5238e..ece31b426013 100644 --- a/net/ipv4/syncookies.c +++ b/net/ipv4/syncookies.c @@ -346,6 +346,7 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb) req->ts_recent = tcp_opt.saw_tstamp ? tcp_opt.rcv_tsval : 0; treq->snt_synack = tcp_opt.saw_tstamp ? tcp_opt.rcv_tsecr : 0; treq->listener = NULL; + ireq->ireq_net = sock_net(sk); /* We throwed the options of the initial SYN away, so we hope * the ACK carries the same options again (see RFC1122 4.2.3.8) |