linux.git/net/ipv4, branch v3.7-rc5

net: inet_diag -- Return error code if protocol handler is missed

2012-11-04T05:56:49+00:00

We've observed that in case if UDP diag module is not
supported in kernel the netlink returns NLMSG_DONE without
notifying a caller that handler is missed.

This patch makes __inet_diag_dump to return error code instead.

So as example it become possible to detect such situation
and handle it gracefully on userspace level.

Signed-off-by: Cyrill Gorcunov 
CC: David Miller 
CC: Eric Dumazet 
CC: Pavel Emelyanov 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

tcp-repair: Handle zero-length data put in rcv queue

2012-11-03T02:01:45+00:00

When sending data into a tcp socket in repair state we should check
for the amount of data being 0 explicitly. Otherwise we'll have an skb
with seq == end_seq in rcv queue, but tcp doesn't expect this to happen
(in particular a warn_on in tcp_recvmsg shoots).

Signed-off-by: Pavel Emelyanov 
Reported-by: Giorgos Mavrikas 
Signed-off-by: David S. Miller

tcp: Fix double sizeof in new tcp_metrics code

2012-11-01T15:59:08+00:00

Fix double sizeof when parsing IPv6 address from
user space because it breaks get/del by specific IPv6 address.

	Problem noticed by David Binderman:

https://bugzilla.kernel.org/show_bug.cgi?id=49171

Signed-off-by: Julian Anastasov 
Signed-off-by: David S. Miller

net: fix divide by zero in tcp algorithm illinois

2012-11-01T15:55:59+00:00

Reading TCP stats when using TCP Illinois congestion control algorithm
can cause a divide by zero kernel oops.

The division by zero occur in tcp_illinois_info() at:
 do_div(t, ca->cnt_rtt);
where ca->cnt_rtt can become zero (when rtt_reset is called)

Steps to Reproduce:
 1. Register tcp_illinois:
     # sysctl -w net.ipv4.tcp_congestion_control=illinois
 2. Monitor internal TCP information via command "ss -i"
     # watch -d ss -i
 3. Establish new TCP conn to machine

Either it fails at the initial conn, or else it needs to wait
for a loss or a reset.

This is only related to reading stats.  The function avg_delay() also
performs the same divide, but is guarded with a (ca->cnt_rtt > 0) at its
calling point in update_params().  Thus, simply fix tcp_illinois_info().

Function tcp_illinois_info() / get_info() is called without
socket lock.  Thus, eliminate any race condition on ca->cnt_rtt
by using a local stack variable.  Simply reuse info.tcpv_rttcnt,
as its already set to ca->cnt_rtt.
Function avg_delay() is not affected by this race condition, as
its called with the socket lock.

Cc: Petr Matousek 
Signed-off-by: Jesper Dangaard Brouer 
Acked-by: Eric Dumazet 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller

Merge branch 'master' of git://1984.lsi.us.es/nf

2012-10-31T18:54:15+00:00

Pablo Neira Ayuso says:

====================
The following patchset contains fixes for your net tree, two of them
are due to relatively recent changes, one has been a longstanding bug,
they are:

* Fix incorrect usage of rt_gateway in the H.323 helper, from
  Julian Anastasov.

* Skip re-route in nf_nat code for ICMP traffic. If CONFIG_XFRM is
  enabled, we waste cycles to look up for the route again. This problem
  seems to be there since really long time. From Ulrich Weber.

* Fix mismatching section in nf_conntrack_reasm, from Hein Tibosch.
====================

Signed-off-by: David S. Miller

netfilter: nf_nat: don't check for port change on ICMP tuples

2012-10-28T21:43:34+00:00

ICMP tuples have id in src and type/code in dst.
So comparing src.u.all with dst.u.all will always fail here
and ip_xfrm_me_harder() is called for every ICMP packet,
even if there was no NAT.

Signed-off-by: Ulrich Weber 
Signed-off-by: Pablo Neira Ayuso

tcp: Reject invalid ack_seq to Fast Open sockets

2012-10-23T06:42:56+00:00

A packet with an invalid ack_seq may cause a TCP Fast Open socket to switch
to the unexpected TCP_CLOSING state, triggering a BUG_ON kernel panic.

When a FIN packet with an invalid ack_seq# arrives at a socket in
the TCP_FIN_WAIT1 state, rather than discarding the packet, the current
code will accept the FIN, causing state transition to TCP_CLOSING.

This may be a small deviation from RFC793, which seems to say that the
packet should be dropped. Unfortunately I did not expect this case for
Fast Open hence it will trigger a BUG_ON panic.

It turns out there is really nothing bad about a TFO socket going into
TCP_CLOSING state so I could just remove the BUG_ON statements. But after
some thought I think it's better to treat this case like TCP_SYN_RECV
and return a RST to the confused peer who caused the unacceptable ack_seq
to be generated in the first place.

Signed-off-by: H.K. Jerry Chu 
Cc: Neal Cardwell 
Cc: Yuchung Cheng 
Acked-by: Yuchung Cheng 
Acked-by: Eric Dumazet 
Acked-by: Neal Cardwell 
Signed-off-by: David S. Miller

tcp: add SYN/data info to TCP_INFO

2012-10-22T19:16:06+00:00

Add a bit TCPI_OPT_SYN_DATA (32) to the socket option TCP_INFO:tcpi_options.
It's set if the data in SYN (sent or received) is acked by SYN-ACK. Server or
client application can use this information to check Fast Open success rate.

Signed-off-by: Yuchung Cheng 
Acked-by: Neal Cardwell 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

tcp: fix FIONREAD/SIOCINQ

2012-10-18T19:34:31+00:00

tcp_ioctl() tries to take into account if tcp socket received a FIN
to report correct number bytes in receive queue.

But its flaky because if the application ate the last skb,
we return 1 instead of 0.

Correct way to detect that FIN was received is to test SOCK_DONE.

Reported-by: Elliot Hughes 
Signed-off-by: Eric Dumazet 
Cc: Neal Cardwell 
Cc: Tom Herbert 
Signed-off-by: David S. Miller

ipv4: Fix flushing of cached routing informations

2012-10-18T19:34:30+00:00

Currently we can not flush cached pmtu/redirect informations via
the ipv4_sysctl_rtcache_flush sysctl. We need to check the rt_genid
of the old route and reset the nh exeption if the old route is
expired when we bind a new route to a nh exeption.

Signed-off-by: Steffen Klassert 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller