linux-toradex.git/net, branch v2.6.28.8

net: Kill skb_truesize_check(), it only catches false-positives.

2009-03-17T00:31:55+00:00

[ Upstream commit 92a0acce186cde8ead56c6915d9479773673ea1a ]

A long time ago we had bugs, primarily in TCP, where we would modify
skb->truesize (for TSO queue collapsing) in ways which would corrupt
the socket memory accounting.

skb_truesize_check() was added in order to try and catch this error
more systematically.

However this debugging check has morphed into a Frankenstein of sorts
and these days it does nothing other than catch false-positives.

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

net: amend the fix for SO_BSDCOMPAT gsopt infoleak

2009-03-17T00:31:54+00:00

[ Upstream commit 50fee1dec5d71b8a14c1b82f2f42e16adc227f8b ]

The fix for CVE-2009-0676 (upstream commit df0bca04) is incomplete. Note
that the same problem of leaking kernel memory will reappear if someone
on some architecture uses struct timeval with some internal padding (for
example tv_sec 64-bit and tv_usec 32-bit) --- then, you are going to
leak the padded bytes to userspace.

Signed-off-by: Eugene Teo 
Reported-by: Mikulas Patocka 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: Fix data corruption when splicing from sockets.

2009-02-17T17:29:05+00:00

[ Upstream commit 8b9d3728977760f6bd1317c4420890f73695354e ]

The trick in socket splicing where we try to convert the skb->data
into a page based reference using virt_to_page() does not work so
well.

The idea is to pass the virt_to_page() reference via the pipe
buffer, and refcount the buffer using a SKB reference.

But if we are splicing from a socket to a socket (via sendpage)
this doesn't work.

The from side processing will grab the page (and SKB) references.
The sendpage() calls will grab page references only, return, and
then the from side processing completes and drops the SKB ref.

The page based reference to skb->data is not enough to keep the
kmalloc() buffer backing it from being reused.  Yet, that is
all that the socket send side has at this point.

This leads to data corruption if the skb->data buffer is reused
by SLAB before the send side socket actually gets the TX packet
out to the device.

The fix employed here is to simply allocate a page and copy the
skb->data bytes into that page.

This will hurt performance, but there is no clear way to fix this
properly without a copy at the present time, and it is important
to get rid of the data corruption.

With fixes from Herbert Xu.

Tested-by: Willy Tarreau 
Foreseen-by: Changli Gao 
Diagnosed-by: Willy Tarreau 
Reported-by: Willy Tarreau 
Fixed-by: Jens Axboe 
Signed-off-by: Jarek Poplawski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: xt_sctp: sctp chunk mapping doesn't work

2009-02-17T17:29:04+00:00

netfilter: xt_sctp: sctp chunk mapping doesn't work

Upstream commit: d4e2675a

When user tries to map all chunks given in argument, kernel
works on a copy of the chunkmap, but at the end it doesn't
check the copy, but the orginal one.

Signed-off-by: Qu Haoran 
Signed-off-by: Nicolas Dichtel 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

netfilter: fix tuple inversion for Node information request

2009-02-17T17:29:03+00:00

netfilter: fix tuple inversion for Node information request

Upstream commit: a51f42f3c

The patch fixes a typo in the inverse mapping of Node Information
request. Following draft-ietf-ipngwg-icmp-name-lookups-09, "Querier"
sends a type 139 (ICMPV6_NI_QUERY) packet to "Responder" which answer
with a type 140 (ICMPV6_NI_REPLY) packet.

Signed-off-by: Eric Leblond 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

tcp: Fix length tcp_splice_data_recv passes to skb_splice_bits.

2009-02-17T17:29:00+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:29:00+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

net: 4 bytes kernel memory disclosure in SO_BSDCOMPAT gsopt try #2

2009-02-17T17:28:57+00:00

[ Upstream commit df0bca049d01c0ee94afb7cd5dfd959541e6c8da ]

In function sock_getsockopt() located in net/core/sock.c, optval v.val
is not correctly initialized and directly returned in userland in case
we have SO_BSDCOMPAT option set.

This dummy code should trigger the bug:

int main(void)
{
	unsigned char buf[4] = { 0, 0, 0, 0 };
	int len;
	int sock;
	sock = socket(33, 2, 2);
	getsockopt(sock, 1, SO_BSDCOMPAT, &buf, &len);
	printf("%x%x%x%x\n", buf[0], buf[1], buf[2], buf[3]);
	close(sock);
}

Here is a patch that fix this bug by initalizing v.val just after its
declaration.

Signed-off-by: Clément Lecigne 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: Copy cork options in ip6_append_data

2009-02-17T17:28:57+00:00

[ Upstream commit 0178b695fd6b40a62a215cbeb03dd51ada3bb5e0 ]

As the options passed to ip6_append_data may be ephemeral, we need
to duplicate it for corking.  This patch applies the simplest fix
which is to memdup all the relevant bits.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: Disallow rediculious flowlabel option sizes.

2009-02-17T17:28:57+00:00

[ Upstream commit 684de409acff8b1fe8bf188d75ff2f99c624387d ]

Just like PKTINFO, limit the options area to 64K.

Based upon report by Eric Sesterhenn and analysis by
Roland Dreier.

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