linux.git/net/core, branch v3.10-rc5

net: fix sk_buff head without data area

2013-06-05T00:26:49+00:00

Eric Dumazet spotted that we have to check skb->head instead
of skb->data as skb->head points to the beginning of the
data area of the skbuff. Similarly, we have to initialize the
skb->head pointer, not skb->data in __alloc_skb_head.

After this fix, netlink crashes in the release path of the
sk_buff, so let's fix that as well.

This bug was introduced in (0ebd0ac net: add function to
allocate sk_buff head without data area).

Reported-by: Eric Dumazet 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: David S. Miller

net/core: dev_mc_sync_multiple calls wrong helper

2013-05-31T23:56:56+00:00

The dev_mc_sync_multiple function is currently calling
__hw_addr_sync, and not __hw_addr_sync_multiple.  This will result in
addresses only being synced to the first device from the set.

	Corrected by calling the _multiple variant.

Signed-off-by: Jay Vosburgh 
Reviewed-by: Vlad Yasevich 
Tested-by: Shawn Bohrer 
Signed-off-by: David S. Miller

net/core: __hw_addr_sync_one / _multiple broken

2013-05-31T23:56:56+00:00

Currently, __hw_addr_sync_one is called in a loop by
__hw_addr_sync_multiple to sync each of a "from" device's hw addresses
to a "to" device.  __hw_addr_sync_one calls __hw_addr_add_ex to attempt
to add each address.  __hw_addr_add_ex is called with global=false, and
sync=true.

	__hw_addr_add_ex checks to see if the new address matches an
address already on the list.  If so, it tests global and sync.  In this
case, sync=true, and it then checks if the address is already synced,
and if so, returns 0.

	This 0 return causes __hw_addr_sync_one to increment the sync_cnt
and refcount for the "from" list's address entry, even though the address
is already synced and has a reference and sync_cnt.  This will cause
the sync_cnt and refcount to increment without bound every time an
addresses is added to the "from" device and synced to the "to" device.

	The fix here has two parts:

	First, when __hw_addr_add_ex finds the address already exists
and is synced, return -EEXIST instead of 0.

	Second, __hw_addr_sync_one checks the error return for -EEXIST,
and if so, it (a) does not add a refcount/sync_cnt, and (b) returns 0
itself so that __hw_addr_sync_multiple will not return an error.

Signed-off-by: Jay Vosburgh 
Reviewed-by: Vlad Yasevich 
Tested-by: Shawn Bohrer 
Signed-off-by: David S. Miller

net/core: __hw_addr_unsync_one "from" address not marked synced

2013-05-31T23:56:56+00:00

When an address is added to a subordinate interface (the "to"
list), the address entry in the "from" list is not marked "synced" as
the entry added to the "to" list is.

	When performing the unsync operation (e.g., dev_mc_unsync),
__hw_addr_unsync_one calls __hw_addr_del_entry with the "synced"
parameter set to true for the case when the address reference is being
released from the "from" list.  This causes a test inside to fail,
with the result being that the reference count on the "from" address
is not properly decremeted and the address on the "from" list will
never be freed.

	Correct this by having __hw_addr_unsync_one call the
__hw_addr_del_entry function with the "sync" flag set to false for the
"remove from the from list" case.

Signed-off-by: Jay Vosburgh 
Reviewed-by: Vlad Yasevich 
Tested-by: Shawn Bohrer 
Signed-off-by: David S. Miller

net/core: __hw_addr_create_ex does not initialize sync_cnt

2013-05-31T23:56:56+00:00

The sync_cnt field is not being initialized, which can result
in arbitrary values in the field.  Fixed by initializing it to zero.

Signed-off-by: Jay Vosburgh 
Reviewed-by: Vlad Yasevich 
Tested-by: Shawn Bohrer 
Signed-off-by: David S. Miller

net/core/sock.c: add missing VSOCK string in af_family_*_key_strings

2013-05-29T06:58:49+00:00

The three arrays of strings: af_family_key_strings,
af_family_slock_key_strings and af_family_clock_key_strings have not
VSOCK's string

Signed-off-by: Federico Vaga 
Signed-off-by: David S. Miller

Hoist memcpy_fromiovec/memcpy_toiovec into lib/

2013-05-20T00:54:22+00:00

ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!

That function is only present with CONFIG_NET.  Turns out that
crypto/algif_skcipher.c also uses that outside net, but it actually
needs sockets anyway.

In addition, commit 6d4f0139d642c45411a47879325891ce2a7c164a added
CONFIG_NET dependency to CONFIG_VMCI for memcpy_toiovec, so hoist
that function and revert that commit too.

socket.h already includes uio.h, so no callers need updating; trying
only broke things fo x86_64 randconfig (thanks Fengguang!).

Reported-by: Randy Dunlap 
Acked-by: David S. Miller 
Acked-by: Michael S. Tsirkin 
Signed-off-by: Rusty Russell

ipv6: do not clear pinet6 field

2013-05-11T23:26:38+00:00

We have seen multiple NULL dereferences in __inet6_lookup_established()

After analysis, I found that inet6_sk() could be NULL while the
check for sk_family == AF_INET6 was true.

Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP
and TCP stacks.

Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash
table, we no longer can clear pinet6 field.

This patch extends logic used in commit fcbdf09d9652c891
("net: fix nulls list corruptions in sk_prot_alloc")

TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method
to make sure we do not clear pinet6 field.

At socket clone phase, we do not really care, as cloning the parent (non
NULL) pinet6 is not adding a fatal race.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

gso: Handle Trans-Ether-Bridging protocol in skb_network_protocol()

2013-05-08T20:13:30+00:00

Rather than having logic to calculate inner protocol in every
tunnel gso handler move it to gso code. This simplifies code.

Cc: Eric Dumazet 
Cc: Cong Wang 
Cc: David S. Miller 
Signed-off-by: Pravin B Shelar 
Signed-off-by: David S. Miller

netpoll: inverted down_trylock() test

2013-05-06T15:06:52+00:00

The return value is reversed from mutex_trylock().

Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller