linux-toradex.git/net, branch v3.2.22

batman-adv: only drop packets of known wifi clients

2012-07-04T04:44:33+00:00

commit 5870adc68fc39d81089f1e80efdf64b97e5c37a1 upstream.

bug introduced with 59b699cdee039d75915c354da06937102d1f9a84

If the source or destination mac address of an ethernet packet
could not be found in the translation table the packet was
dropped if AP isolation was turned on. This behavior would
make it impossible to send broadcast packets over the mesh as
the broadcast address will never enter the translation table.

Signed-off-by: Marek Lindner 
Acked-by: Antonio Quartulli 
Signed-off-by: Ben Hutchings

batman-adv: fix skb->data assignment

2012-07-04T04:44:21+00:00

commit 2c995ff892313009e336ecc8ec3411022f5b1c39 upstream.

skb_linearize(skb) possibly rearranges the skb internal data and then changes
the skb->data pointer value. For this reason any other pointer in the code that
was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.

In the current tt_query message handling code this is not done and therefore, in
case of skb linearization, the pointer used to handle the packet header ends up
in pointing to free'd memory.

This bug was introduced by a73105b8d4c765d9ebfb664d0a66802127d8e4c7
(batman-adv: improved client announcement mechanism)

Signed-off-by: Antonio Quartulli 
Signed-off-by: David S. Miller 
[This patch is a backport for kernel versions 3.1 and 3.2 - Antonio]
Signed-off-by: Ben Hutchings

cfg80211: fix potential deadlock in regulatory

2012-07-04T04:44:18+00:00

commit fe20b39ec32e975f1054c0b7866c873a954adf05 upstream.

reg_timeout_work() calls restore_regulatory_settings() which
takes cfg80211_mutex.

reg_set_request_processed() already holds cfg80211_mutex
before calling cancel_delayed_work_sync(reg_timeout),
so it might deadlock.

Call the async cancel_delayed_work instead, in order
to avoid the potential deadlock.

This is the relevant lockdep warning:

cfg80211: Calling CRDA for country: XX

======================================================
[ INFO: possible circular locking dependency detected ]
3.4.0-rc5-wl+ #26 Not tainted
-------------------------------------------------------
kworker/0:2/1391 is trying to acquire lock:
 (cfg80211_mutex){+.+.+.}, at: [] restore_regulatory_settings+0x34/0x418 [cfg80211]

but task is already holding lock:
 ((reg_timeout).work){+.+...}, at: [] process_one_work+0x1f0/0x480

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 ((reg_timeout).work){+.+...}:
       [] validate_chain+0xb94/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] wait_on_work+0x4c/0x154
       [] __cancel_work_timer+0xd4/0x11c
       [] cancel_delayed_work_sync+0x1c/0x20
       [] reg_set_request_processed+0x50/0x78 [cfg80211]
       [] set_regdom+0x550/0x600 [cfg80211]
       [] nl80211_set_reg+0x218/0x258 [cfg80211]
       [] genl_rcv_msg+0x1a8/0x1e8
       [] netlink_rcv_skb+0x5c/0xc0
       [] genl_rcv+0x28/0x34
       [] netlink_unicast+0x15c/0x228
       [] netlink_sendmsg+0x218/0x298
       [] sock_sendmsg+0xa4/0xc0
       [] __sys_sendmsg+0x1e4/0x268
       [] sys_sendmsg+0x4c/0x70
       [] ret_fast_syscall+0x0/0x3c

-> #1 (reg_mutex){+.+.+.}:
       [] validate_chain+0xb94/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] mutex_lock_nested+0x48/0x320
       [] reg_todo+0x30/0x538 [cfg80211]
       [] process_one_work+0x2a0/0x480
       [] worker_thread+0x1bc/0x2bc
       [] kthread+0x98/0xa4
       [] kernel_thread_exit+0x0/0x8

-> #0 (cfg80211_mutex){+.+.+.}:
       [] print_circular_bug+0x68/0x2cc
       [] validate_chain+0x978/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] mutex_lock_nested+0x48/0x320
       [] restore_regulatory_settings+0x34/0x418 [cfg80211]
       [] reg_timeout_work+0x1c/0x20 [cfg80211]
       [] process_one_work+0x2a0/0x480
       [] worker_thread+0x1bc/0x2bc
       [] kthread+0x98/0xa4
       [] kernel_thread_exit+0x0/0x8

other info that might help us debug this:

Chain exists of:
  cfg80211_mutex --> reg_mutex --> (reg_timeout).work

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((reg_timeout).work);
                               lock(reg_mutex);
                               lock((reg_timeout).work);
  lock(cfg80211_mutex);

 *** DEADLOCK ***

2 locks held by kworker/0:2/1391:
 #0:  (events){.+.+.+}, at: [] process_one_work+0x1f0/0x480
 #1:  ((reg_timeout).work){+.+...}, at: [] process_one_work+0x1f0/0x480

stack backtrace:
[] (unwind_backtrace+0x0/0x12c) from [] (dump_stack+0x20/0x24)
[] (dump_stack+0x20/0x24) from [] (print_circular_bug+0x280/0x2cc)
[] (print_circular_bug+0x280/0x2cc) from [] (validate_chain+0x978/0x10f0)
[] (validate_chain+0x978/0x10f0) from [] (__lock_acquire+0x8c8/0x9b0)
[] (__lock_acquire+0x8c8/0x9b0) from [] (lock_acquire+0xf0/0x114)
[] (lock_acquire+0xf0/0x114) from [] (mutex_lock_nested+0x48/0x320)
[] (mutex_lock_nested+0x48/0x320) from [] (restore_regulatory_settings+0x34/0x418 [cfg80211])
[] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [] (reg_timeout_work+0x1c/0x20 [cfg80211])
[] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [] (process_one_work+0x2a0/0x480)
[] (process_one_work+0x2a0/0x480) from [] (worker_thread+0x1bc/0x2bc)
[] (worker_thread+0x1bc/0x2bc) from [] (kthread+0x98/0xa4)
[] (kthread+0x98/0xa4) from [] (kernel_thread_exit+0x0/0x8)
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

Signed-off-by: Eliad Peller 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

cfg80211: fix interface combinations check

2012-06-19T22:18:14+00:00

commit 463454b5dbd8dbab6e2fc6c557329e5b811b9c32 upstream.

If a given interface combination doesn't contain
a required interface type then we missed checking
that and erroneously allowed it even though iface
type wasn't there at all. Add a check that makes
sure that all interface types are accounted for.

Reported-by: Mohammed Shafi Shajakhan 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

mac80211: clean up remain-on-channel on interface stop

2012-06-19T22:18:11+00:00

commit 71ecfa1893034eeb1c93e02e22ee2ad26d080858 upstream.

When any interface goes down, it could be the one that we
were doing a remain-on-channel with. We therefore need to
cancel the remain-on-channel and flush the related work
structs so they don't run after the interface has been
removed or even destroyed.

It's also possible in this case that an off-channel SKB
was never transmitted, so free it if this is the case.
Note that this can also happen if the driver finishes
the off-channel period without ever starting it.

Reported-by: Nirav Shah 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

NFSv4.1: Fix a request leak on the back channel

2012-06-19T22:18:08+00:00

commit b3b02ae5865c2dcd506322e0fc6def59a042e72f upstream.

If the call to svc_process_common() fails, then the request
needs to be freed before we can exit bc_svc_process.

Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

xfrm: take net hdr len into account for esp payload size calculation

2012-06-10T13:42:07+00:00

[ Upstream commit 91657eafb64b4cb53ec3a2fbc4afc3497f735788 ]

Corrects the function that determines the esp payload size. The calculations
done in esp{4,6}_get_mtu() lead to overlength frames in transport mode for
certain mtu values and suboptimal frames for others.

According to what is done, mainly in esp{,6}_output() and tcp_mtu_to_mss(),
net_header_len must be taken into account before doing the alignment
calculation.

Signed-off-by: Benjamin Poirier 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

sctp: check cached dst before using it

2012-06-10T13:42:06+00:00

[ Upstream commit e0268868ba064980488fc8c194db3d8e9fb2959c ]

dst_check() will take care of SA (and obsolete field), hence
IPsec rekeying scenario is taken into account.

Signed-off-by: Nicolas Dichtel 
Acked-by: Vlad Yaseivch 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

Revert "net: maintain namespace isolation between vlan and real device"

2012-06-10T13:42:05+00:00

[ Upstream commit 59b9997baba5242997ddc7bd96b1391f5275a5a4 ]

This reverts commit 8a83a00b0735190384a348156837918271034144.

It causes regressions for S390 devices, because it does an
unconditional DST drop on SKBs for vlans and the QETH device
needs the neighbour entry hung off the DST for certain things
on transmit.

Arnd can't remember exactly why he even needed this change.

Conflicts:

	drivers/net/macvlan.c
	net/8021q/vlan_dev.c
	net/core/dev.c

Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case

2012-06-10T13:42:03+00:00

[ Upstream commit c51ce49735c183ef2592db70f918ee698716276b ]

An application may call connect() to disconnect a socket using an
address with family AF_UNSPEC. The L2TP IP sockets were not handling
this case when the socket is not bound and an attempt to connect()
using AF_UNSPEC in such cases would result in an oops. This patch
addresses the problem by protecting the sk_prot->disconnect() call
against trying to unhash the socket before it is bound.

The patch also adds more checks that the sockaddr supplied to bind()
and connect() calls is valid.

 RIP: 0010:[]  [] inet_unhash+0x50/0xd0
 RSP: 0018:ffff88001989be28  EFLAGS: 00010293
 Stack:
  ffff8800407a8000 0000000000000000 ffff88001989be78 ffffffff82e3a249
  ffffffff82e3a050 ffff88001989bec8 ffff88001989be88 ffff8800407a8000
  0000000000000010 ffff88001989bec8 ffff88001989bea8 ffffffff82e42639
 Call Trace:
 [] udp_disconnect+0x1f9/0x290
 [] inet_dgram_connect+0x29/0x80
 [] sys_connect+0x9c/0x100

Reported-by: Sasha Levin 
Signed-off-by: James Chapman 
Signed-off-by: Ben Hutchings