linux-toradex.git/net/core, branch v2.6.34.2

ethtool: Fix potential user buffer overflow for ETHTOOL_{G, S}RXFH

2010-08-02T17:30:05+00:00

commit bf988435bd5b53529f4408a8efb1f433f6ddfda9 upstream.

struct ethtool_rxnfc was originally defined in 2.6.27 for the
ETHTOOL_{G,S}RXFH command with only the cmd, flow_type and data
fields.  It was then extended in 2.6.30 to support various additional
commands.  These commands should have been defined to use a new
structure, but it is too late to change that now.

Since user-space may still be using the old structure definition
for the ETHTOOL_{G,S}RXFH commands, and since they do not need the
additional fields, only copy the originally defined fields to and
from user-space.

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

ethtool: Fix potential kernel buffer overflow in ETHTOOL_GRXCLSRLALL

2010-08-02T17:29:49+00:00

commit db048b69037e7fa6a7d9e95a1271a50dc08ae233 upstream.

On a 32-bit machine, info.rule_cnt >= 0x40000000 leads to integer
overflow and the buffer may be smaller than needed.  Since
ETHTOOL_GRXCLSRLALL is unprivileged, this can presumably be used for at
least denial of service.

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

net/core: neighbour update Oops

2010-08-02T17:29:28+00:00

commit 91a72a70594e5212c97705ca6a694bd307f7a26b upstream.

When configuring DMVPN (GRE + openNHRP) and a GRE remote
address is configured a kernel Oops is observed.  The
obserseved Oops is caused by a NULL header_ops pointer
(neigh->dev->header_ops) in neigh_update_hhs() when

void (*update)(struct hh_cache*, const struct net_device*, const unsigned char *)
= neigh->dev->header_ops->cache_update;

is executed.  The dev associated with the NULL header_ops is
the GRE interface.  This patch guards against the
possibility that header_ops is NULL.

This Oops was first observed in kernel version 2.6.26.8.

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

net: fix problem in reading sock TX queue

2010-08-02T17:29:27+00:00

commit b0f77d0eae0c58a5a9691a067ada112ceeae2d00 upstream.

Fix problem in reading the tx_queue recorded in a socket.  In
dev_pick_tx, the TX queue is read by doing a check with
sk_tx_queue_recorded on the socket, followed by a sk_tx_queue_get.
The problem is that there is not mutual exclusion across these
calls in the socket so it it is possible that the queue in the
sock can be invalidated after sk_tx_queue_recorded is called so
that sk_tx_queue get returns -1, which sets 65535 in queue_index
and thus dev_pick_tx returns 65536 which is a bogus queue and
can cause crash in dev_queue_xmit.

We fix this by only calling sk_tx_queue_get which does the proper
checks.  The interface is that sk_tx_queue_get returns the TX queue
if the sock argument is non-NULL and TX queue is recorded, else it
returns -1.  sk_tx_queue_recorded is no longer used so it can be
completely removed.

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

gro: Fix bogus gso_size on the first fraglist entry

2010-08-02T17:29:18+00:00

[ Upstream commit 622e0ca1cd4d459f5af4f2c65f4dc0dd823cb4c3 ]

When GRO produces fraglist entries, and the resulting skb hits
an interface that is incapable of TSO but capable of FRAGLIST,
we end up producing a bogus packet with gso_size non-zero.

This was reported in the field with older versions of KVM that
did not set the TSO bits on tuntap.

This patch fixes that.

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

rtnetlink: make SR-IOV VF interface symmetric

2010-05-16T08:05:45+00:00

Now we have a set of nested attributes:

  IFLA_VFINFO_LIST (NESTED)
    IFLA_VF_INFO (NESTED)
      IFLA_VF_MAC
      IFLA_VF_VLAN
      IFLA_VF_TX_RATE

This allows a single set to operate on multiple attributes if desired.
Among other things, it means a dump can be replayed to set state.

The current interface has yet to be released, so this seems like
something to consider for 2.6.34.

Signed-off-by: Chris Wright 
Signed-off-by: David S. Miller

veth: Dont kfree_skb() after dev_forward_skb()

2010-05-06T07:53:53+00:00

In case of congestion, netif_rx() frees the skb, so we must assume
dev_forward_skb() also consume skb.

Bug introduced by commit 445409602c092
(veth: move loopback logic to common location)

We must change dev_forward_skb() to always consume skb, and veth to not
double free it.

Bug report : http://marc.info/?l=linux-netdev&m=127310770900442&w=3

Reported-by: Martín Ferrari 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

rtnetlink: potential ERR_PTR dereference

2010-04-22T22:57:26+00:00

In the original code, if rtnl_create_link() returned an ERR_PTR then that
would get passed to rtnl_configure_link() which dereferences it.

Signed-off-by: Dan Carpenter 
Acked-by: Patrick McHardy 
Signed-off-by: David S. Miller

net: Fix an RCU warning in dev_pick_tx()

2010-04-21T08:09:44+00:00

Fix the following RCU warning in dev_pick_tx():

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
net/core/dev.c:1993 invoked rcu_dereference_check() without protection!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
2 locks held by swapper/0:
 #0:  (&idev->mc_ifc_timer){+.-...}, at: [] run_timer_softirq+0x17b/0x278
 #1:  (rcu_read_lock_bh){.+....}, at: [] dev_queue_xmit+0x14e/0x4dc

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.34-rc5-cachefs #4
Call Trace:
   [] lockdep_rcu_dereference+0xaa/0xb2
 [] dev_queue_xmit+0x259/0x4dc
 [] ? dev_queue_xmit+0x14e/0x4dc
 [] ? trace_hardirqs_on+0xd/0xf
 [] ? local_bh_enable_ip+0xbc/0xc1
 [] neigh_resolve_output+0x24b/0x27c
 [] ip6_output_finish+0x7c/0xb4
 [] ip6_output2+0x256/0x261
 [] ? trace_hardirqs_on+0xd/0xf
 [] ip6_output+0xbbc/0xbcb
 [] ? fib6_force_start_gc+0x2b/0x2d
 [] mld_sendpack+0x273/0x39d
 [] ? mld_sendpack+0x0/0x39d
 [] ? mark_held_locks+0x52/0x70
 [] mld_ifc_timer_expire+0x24f/0x288
 [] run_timer_softirq+0x1ec/0x278
 [] ? run_timer_softirq+0x17b/0x278
 [] ? mld_ifc_timer_expire+0x0/0x288
 [] ? __do_softirq+0x69/0x140
 [] __do_softirq+0xa2/0x140
 [] call_softirq+0x1c/0x28
 [] do_softirq+0x38/0x80
 [] irq_exit+0x45/0x47
 [] smp_apic_timer_interrupt+0x88/0x96
 [] apic_timer_interrupt+0x13/0x20
   [] ? __atomic_notifier_call_chain+0x0/0x86
 [] ? mwait_idle+0x6e/0x78
 [] ? mwait_idle+0x65/0x78
 [] cpu_idle+0x4d/0x83
 [] rest_init+0xb9/0xc0
 [] ? rest_init+0x0/0xc0
 [] start_kernel+0x392/0x39d
 [] x86_64_start_reservations+0xb3/0xb7
 [] x86_64_start_kernel+0xe4/0xeb

An rcu_dereference() should be an rcu_dereference_bh().

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

net: dev_pick_tx() fix

2010-04-15T08:27:11+00:00

When dev_pick_tx() caches tx queue_index on a socket, we must check
socket dst_entry matches skb one, or risk a crash later, as reported by
Denys Fedorysychenko, if old packets are in flight during a route
change, involving devices with different number of queues.

Bug introduced by commit a4ee3ce3
(net: Use sk_tx_queue_mapping for connected sockets)

Reported-by: Denys Fedorysychenko 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller