linux-toradex.git/net/ipv4, branch v2.6.27.24

netfilter: {ip, ip6, arp}_tables: fix incorrect loop detection

2009-05-02T17:24:08+00:00

upstream commit: 1f9352ae2253a97b07b34dcf16ffa3b4ca12c558

Commit e1b4b9f ([NETFILTER]: {ip,ip6,arp}_tables: fix exponential worst-case
search for loops) introduced a regression in the loop detection algorithm,
causing sporadic incorrectly detected loops.

When a chain has already been visited during the check, it is treated as
having a standard target containing a RETURN verdict directly at the
beginning in order to not check it again. The real target of the first
rule is then incorrectly treated as STANDARD target and checked not to
contain invalid verdicts.

Fix by making sure the rule does actually contain a standard target.

Based on patch by Francis Dupont 
Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

tcp: Fix length tcp_splice_data_recv passes to skb_splice_bits.

2009-02-17T17:46:25+00:00

[ Upstream commit 9fa5fdf291c9b58b1cb8b4bb2a0ee57efa21d635 ]

tcp_splice_data_recv has two lengths to consider: the len parameter it
gets from tcp_read_sock, which specifies the amount of data in the skb,
and rd_desc->count, which is the amount of data the splice caller still
wants.  Currently it passes just the latter to skb_splice_bits, which then
splices min(rd_desc->count, skb->len - offset) bytes.

Most of the time this is fine, except when the skb contains urgent data.
In that case len goes only up to the urgent byte and is less than
skb->len - offset.  By ignoring len tcp_splice_data_recv may a) splice
data tcp_read_sock told it not to, b) return to tcp_read_sock a value > len.

Now, tcp_read_sock doesn't handle used > len and leaves the socket in a
bad state (both sk_receive_queue and copied_seq are bad at that point)
resulting in duplicated data and corruption.

Fix by passing min(rd_desc->count, len) to skb_splice_bits.

Signed-off-by: Dimitris Michailidis 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: splice as many packets as possible at once

2009-02-17T17:46:25+00:00

[ Upstream commit 33966dd0e2f68f26943cd9ee93ec6abbc6547a8e ]

As spotted by Willy Tarreau, current splice() from tcp socket to pipe is not
optimal. It processes at most one segment per call.
This results in low performance and very high overhead due to syscall rate
when splicing from interfaces which do not support LRO.

Willy provided a patch inside tcp_splice_read(), but a better fix
is to let tcp_read_sock() process as many segments as possible, so
that tcp_rcv_space_adjust() and tcp_cleanup_rbuf() are called less
often.

With this change, splice() behaves like tcp_recvmsg(), being able
to consume many skbs in one system call. With typical 1460 bytes
of payload per frame, that means splice(SPLICE_F_NONBLOCK) can return
16*1460 = 23360 bytes.

Signed-off-by: Willy Tarreau 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

udp: increments sk_drops in __udp_queue_rcv_skb()

2009-02-17T17:46:23+00:00

[ Upstream commit e408b8dcb5ce42243a902205005208e590f28454 ]

Commit 93821778def10ec1e69aa3ac10adee975dad4ff3 (udp: Fix rcv socket
locking) accidentally removed sk_drops increments for UDP IPV4
sockets.

This field can be used to detect incorrect sizing of socket receive
buffers.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

udp: Fix UDP short packet false positive

2009-02-17T17:46:23+00:00

[ Upstream commit 7b5e56f9d635643ad54f2f42e69ad16b80a2cff1 ]

The UDP header pointer assignment must happen after calling
pskb_may_pull().  As pskb_may_pull() can potentially alter the SKB
buffer.

This was exposted by running multicast traffic through the NIU driver,
as it won't prepull the protocol headers into the linear area on
receive.

Signed-off-by: Jesper Dangaard Brouer 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv4: fix infinite retry loop in IP-Config

2009-02-17T17:46:20+00:00

[ Upstream commit 9d8dba6c979fa99c96938c869611b9a23b73efa9 ]

Signed-off-by: Benjamin Zores 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: don't mask EOF and socket errors on nonblocking splice receive

2009-01-25T00:36:19+00:00

[ Upstream commit: 4f7d54f59bc470f0aaa932f747a95232d7ebf8b1 ]

Currently, setting SPLICE_F_NONBLOCK on splice from a TCP socket
results in masking of EOF (RDHUP) and error conditions on the socket
by an -EAGAIN return.  Move the NONBLOCK check in tcp_splice_read()
to be after the EOF and error checks to fix this.

Signed-off-by: Lennert Buytenhek 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

udp: multicast packets need to check namespace

2008-12-13T23:29:12+00:00

[ Upstream commit 920a46115ca3fa88990276d98520abab85495b2d ]

Current UDP multicast delivery is not namespace aware.

Signed-off-by: Eric Dumazet 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: fix /proc/net/snmp as memory corruptor

2008-11-20T22:54:48+00:00

commit b971e7ac834e9f4bda96d5a96ae9abccd01c1dd8 upstream.

icmpmsg_put() can happily corrupt kernel memory, using a static
table and forgetting to reset an array index in a loop.

Remove the static array since its not safe without proper locking.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: Restore ordering of TCP options for the sake of inter-operability

2008-11-07T03:05:41+00:00

[ Upstream commit fd6149d332973bafa50f03ddb0ea9513e67f4517 ]

This is not our bug! Sadly some devices cannot cope with the change
of TCP option ordering which was a result of the recent rewrite of
the option code (not that there was some particular reason steming
from the rewrite for the reordering) though any ordering of TCP
options is perfectly legal. Thus we restore the original ordering
to allow interoperability with/through such broken devices and add
some warning about this trap. Since the reordering just happened
without any particular reason, this change shouldn't cost us
anything.

There are already couple of known failure reports (within close
proximity of the last release), so the problem might be more
wide-spread than a single device. And other reports which may
be due to the same problem though the symptoms were less obvious.
Analysis of one of the case revealed (with very high probability)
that sack capability cannot be negotiated as the first option
(SYN never got a response).

Signed-off-by: Ilpo Järvinen 
Reported-by: Aldo Maggi 
Tested-by: Aldo Maggi 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman