linux-stable.git/net, branch v3.0.38

cfg80211: check iface combinations only when iface is running

2012-07-19T15:58:22+00:00

commit f8cdddb8d61d16a156229f0910f7ecfc7a82c003 upstream.

Don't validate interface combinations on a stopped
interface. Otherwise we might end up being able to
create a new interface with a certain type, but
won't be able to change an existing interface
into that type.

This also skips some other functions when
interface is stopped and changing interface type.

Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg 
[Fixes regression introduced by cherry pick of 463454b5dbd8]
Signed-off-by: Paul Gortmaker

tcp: drop SYN+FIN messages

2012-07-19T15:58:22+00:00

commit fdf5af0daf8019cec2396cdef8fb042d80fe71fa upstream.

Denys Fedoryshchenko reported that SYN+FIN attacks were bringing his
linux machines to their limits.

Dont call conn_request() if the TCP flags includes SYN flag

Reported-by: Denys Fedoryshchenko 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

mac80211: correct behaviour on unrecognised action frames

2012-07-16T15:47:49+00:00

commit 4b5ebccc40843104d980f0714bc86bfcd5568941 upstream.

When receiving an "individually addressed" action frame, the
receiver is required to return it to the sender. mac80211
gets this wrong as it also returns group addressed (mcast)
frames to the sender. Fix this and update the reference to
the new 802.11 standards version since things were shuffled
around significantly.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix potential deadlock in regulatory

2012-07-16T15:47:48+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: Greg Kroah-Hartman

netpoll: fix netpoll_send_udp() bugs

2012-07-16T15:47:38+00:00

[ Upstream commit 954fba0274058d27c7c07b5ea07c41b3b7477894 ]

Bogdan Hamciuc diagnosed and fixed following bug in netpoll_send_udp() :

"skb->len += len;" instead of "skb_put(skb, len);"

Meaning that _if_ a network driver needs to call skb_realloc_headroom(),
only packet headers would be copied, leaving garbage in the payload.

However the skb_realloc_headroom() must be avoided as much as possible
since it requires memory and netpoll tries hard to work even if memory
is exhausted (using a pool of preallocated skbs)

It appears netpoll_send_udp() reserved 16 bytes for the ethernet header,
which happens to work for typicall drivers but not all.

Right thing is to use LL_RESERVED_SPACE(dev)
(And also add dev->needed_tailroom of tailroom)

This patch combines both fixes.

Many thanks to Bogdan for raising this issue.

Reported-by: Bogdan Hamciuc 
Signed-off-by: Eric Dumazet 
Tested-by: Bogdan Hamciuc 
Cc: Herbert Xu 
Cc: Neil Horman 
Reviewed-by: Neil Horman 
Reviewed-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: Move ipv6 proc file registration to end of init order

2012-07-16T15:47:37+00:00

[ Upstream commit d189634ecab947c10f6f832258b103d0bbfe73cc ]

/proc/net/ipv6_route reflects the contents of fib_table_hash. The proc
handler is installed in ip6_route_net_init() whereas fib_table_hash is
allocated in fib6_net_init() _after_ the proc handler has been installed.

This opens up a short time frame to access fib_table_hash with its pants
down.

Move the registration of the proc files to a later point in the init
order to avoid the race.

Tested :-)

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

bridge: Assign rtnl_link_ops to bridge devices created via ioctl (v2)

2012-07-16T15:47:37+00:00

[ Upstream commit 149ddd83a92b02c658d6c61f3276eb6500d585e8 ]

This ensures that bridges created with brctl(8) or ioctl(2) directly
also carry IFLA_LINKINFO when dumped over netlink. This also allows
to create a bridge with ioctl(2) and delete it with RTM_DELLINK.

Signed-off-by: Thomas Graf 
Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ethtool: allow ETHTOOL_GSSET_INFO for users

2012-07-16T15:47:37+00:00

[ Upstream commit f80400a26a2e8bff541de12834a1134358bb6642 ]

Allow ETHTOOL_GSSET_INFO ethtool ioctl() for unprivileged users.
ETHTOOL_GSTRINGS is already allowed, but is unusable without this one.

Signed-off-by: Micha©© Miros©©aw 
Acked-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: l2tp_eth: fix kernel panic on rmmod l2tp_eth

2012-07-16T15:47:36+00:00

[ Upstream commit a06998b88b1651c5f71c0e35f528bf2057188ead ]

We must prevent module unloading if some devices are still attached to
l2tp_eth driver.

Signed-off-by: Eric Dumazet 
Reported-by: Denys Fedoryshchenko 
Tested-by: Denys Fedoryshchenko 
Cc: James Chapman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()

2012-07-16T15:47:36+00:00

[ Upstream commit cc9b17ad29ecaa20bfe426a8d4dbfb94b13ff1cc ]

We need to validate the number of pages consumed by data_len, otherwise frags
array could be overflowed by userspace. So this patch validate data_len and
return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS.

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