linux.git/net, branch v3.15-rc2

net: sctp: cache auth_enable per endpoint

2014-04-18T22:32:00+00:00

Currently, it is possible to create an SCTP socket, then switch
auth_enable via sysctl setting to 1 and crash the system on connect:

Oops[#1]:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.1-mipsgit-20140415 #1
task: ffffffff8056ce80 ti: ffffffff8055c000 task.ti: ffffffff8055c000
[...]
Call Trace:
[] sctp_auth_asoc_set_default_hmac+0x68/0x80
[] sctp_process_init+0x5e0/0x8a4
[] sctp_sf_do_5_1B_init+0x234/0x34c
[] sctp_do_sm+0xb4/0x1e8
[] sctp_endpoint_bh_rcv+0x1c4/0x214
[] sctp_rcv+0x588/0x630
[] sctp6_rcv+0x10/0x24
[] ip6_input+0x2c0/0x440
[] __netif_receive_skb_core+0x4a8/0x564
[] process_backlog+0xb4/0x18c
[] net_rx_action+0x12c/0x210
[] __do_softirq+0x17c/0x2ac
[] irq_exit+0x54/0xb0
[] ret_from_irq+0x0/0x4
[] rm7k_wait_irqoff+0x24/0x48
[] cpu_startup_entry+0xc0/0x148
[] start_kernel+0x37c/0x398
Code: dd0900b8  000330f8  0126302d  50c0fff1  0047182a  a48306a0
03e00008  00000000
---[ end trace b530b0551467f2fd ]---
Kernel panic - not syncing: Fatal exception in interrupt

What happens while auth_enable=0 in that case is, that
ep->auth_hmacs is initialized to NULL in sctp_auth_init_hmacs()
when endpoint is being created.

After that point, if an admin switches over to auth_enable=1,
the machine can crash due to NULL pointer dereference during
reception of an INIT chunk. When we enter sctp_process_init()
via sctp_sf_do_5_1B_init() in order to respond to an INIT chunk,
the INIT verification succeeds and while we walk and process
all INIT params via sctp_process_param() we find that
net->sctp.auth_enable is set, therefore do not fall through,
but invoke sctp_auth_asoc_set_default_hmac() instead, and thus,
dereference what we have set to NULL during endpoint
initialization phase.

The fix is to make auth_enable immutable by caching its value
during endpoint initialization, so that its original value is
being carried along until destruction. The bug seems to originate
from the very first days.

Fix in joint work with Daniel Borkmann.

Reported-by: Joshua Kinard 
Signed-off-by: Vlad Yasevich 
Signed-off-by: Daniel Borkmann 
Acked-by: Neil Horman 
Tested-by: Joshua Kinard 
Signed-off-by: David S. Miller

Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

2014-04-18T22:29:44+00:00

John W. Linville says:

====================
pull request: wireless 2014-04-17

Please pull this batch of fixes intended for the 3.15 stream...

For the mac80211 bits, Johannes says:

"We have a fix from Chun-Yeow to not look at management frame bitrates
that are typically really low, two fixes from Felix for AP_VLAN
interfaces, a fix from Ido to disable SMPS settings when a monitor
interface is enabled, a radar detection fix from Michał and a fix from
myself for a very old remain-on-channel bug."

For the iwlwifi bits, Emmanuel says:

"I have new device IDs and a new firmware API. These are the trivial
ones. The less trivial ones are Johannes's fix that delays the
enablement of an interrupt coalescing hardware until after association
- this fixes a few connection problems seen in the field. Eyal has a
bunch of rate control fixes. I decided to add these for 3.15 because
they fix some disconnection and packet loss scenarios which were
reported by the field. I also have a fix for a memory leak that
happens only with a very new NIC."

Along with those...

Amitkumar Karwar fixes a couple of problems relating to driver/firmware
interactions in mwifiex.

Christian Engelmayer avoids a couple of potential memory leaks in
the new rsi driver.

Eliad Peller provides a wl18xx mailbox alignment fix for problems
when using new firmware.

Frederic Danis adds a couple of missing debugging strings to the
cw1200 driver.

Geert Uytterhoeven adds a variable initialization inside of the
rsi driver.

Luciano Coelho patches the wlcore code to ignore dummy packet events
in PLT mode in order to work around a firmware bug.
====================

Signed-off-by: David S. Miller

vlan: Fix lockdep warning when vlan dev handle notification

2014-04-18T21:48:30+00:00

When I open the LOCKDEP config and run these steps:

modprobe 8021q
vconfig add eth2 20
vconfig add eth2.20 30
ifconfig eth2 xx.xx.xx.xx

then the Call Trace happened:

[32524.386288] =============================================
[32524.386293] [ INFO: possible recursive locking detected ]
[32524.386298] 3.14.0-rc2-0.7-default+ #35 Tainted: G           O
[32524.386302] ---------------------------------------------
[32524.386306] ifconfig/3103 is trying to acquire lock:
[32524.386310]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_mc_sync+0x64/0xb0
[32524.386326]
[32524.386326] but task is already holding lock:
[32524.386330]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_set_rx_mode+0x23/0x40
[32524.386341]
[32524.386341] other info that might help us debug this:
[32524.386345]  Possible unsafe locking scenario:
[32524.386345]
[32524.386350]        CPU0
[32524.386352]        ----
[32524.386354]   lock(&vlan_netdev_addr_lock_key/1);
[32524.386359]   lock(&vlan_netdev_addr_lock_key/1);
[32524.386364]
[32524.386364]  *** DEADLOCK ***
[32524.386364]
[32524.386368]  May be due to missing lock nesting notation
[32524.386368]
[32524.386373] 2 locks held by ifconfig/3103:
[32524.386376]  #0:  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20
[32524.386387]  #1:  (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_set_rx_mode+0x23/0x40
[32524.386398]
[32524.386398] stack backtrace:
[32524.386403] CPU: 1 PID: 3103 Comm: ifconfig Tainted: G           O 3.14.0-rc2-0.7-default+ #35
[32524.386409] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[32524.386414]  ffffffff81ffae40 ffff8800d9625ae8 ffffffff814f68a2 ffff8800d9625bc8
[32524.386421]  ffffffff810a35fb ffff8800d8a8d9d0 00000000d9625b28 ffff8800d8a8e5d0
[32524.386428]  000003cc00000000 0000000000000002 ffff8800d8a8e5f8 0000000000000000
[32524.386435] Call Trace:
[32524.386441]  [] dump_stack+0x6a/0x78
[32524.386448]  [] __lock_acquire+0x7ab/0x1940
[32524.386454]  [] ? __lock_acquire+0x3ea/0x1940
[32524.386459]  [] lock_acquire+0xe4/0x110
[32524.386464]  [] ? dev_mc_sync+0x64/0xb0
[32524.386471]  [] _raw_spin_lock_nested+0x2a/0x40
[32524.386476]  [] ? dev_mc_sync+0x64/0xb0
[32524.386481]  [] dev_mc_sync+0x64/0xb0
[32524.386489]  [] vlan_dev_set_rx_mode+0x2b/0x50 [8021q]
[32524.386495]  [] __dev_set_rx_mode+0x5f/0xb0
[32524.386500]  [] dev_set_rx_mode+0x2b/0x40
[32524.386506]  [] __dev_open+0xef/0x150
[32524.386511]  [] __dev_change_flags+0xa7/0x190
[32524.386516]  [] dev_change_flags+0x32/0x80
[32524.386524]  [] devinet_ioctl+0x7d6/0x830
[32524.386532]  [] ? dev_ioctl+0x34b/0x660
[32524.386540]  [] inet_ioctl+0x80/0xa0
[32524.386550]  [] sock_do_ioctl+0x2d/0x60
[32524.386558]  [] sock_ioctl+0x82/0x2a0
[32524.386568]  [] do_vfs_ioctl+0x93/0x590
[32524.386578]  [] ? rcu_read_lock_held+0x45/0x50
[32524.386586]  [] ? __fget_light+0x105/0x110
[32524.386594]  [] SyS_ioctl+0x91/0xb0
[32524.386604]  [] system_call_fastpath+0x16/0x1b

========================================================================

The reason is that all of the addr_lock_key for vlan dev have the same class,
so if we change the status for vlan dev, the vlan dev and its real dev will
hold the same class of addr_lock_key together, so the warning happened.

we should distinguish the lock depth for vlan dev and its real dev.

v1->v2: Convert the vlan_netdev_addr_lock_key to an array of eight elements, which
	could support to add 8 vlan id on a same vlan dev, I think it is enough for current
	scene, because a netdev's name is limited to IFNAMSIZ which could not hold 8 vlan id,
	and the vlan dev would not meet the same class key with its real dev.

	The new function vlan_dev_get_lockdep_subkey() will return the subkey and make the vlan
	dev could get a suitable class key.

v2->v3: According David's suggestion, I use the subclass to distinguish the lock key for vlan dev
	and its real dev, but it make no sense, because the difference for subclass in the
	lock_class_key doesn't mean that the difference class for lock_key, so I use lock_depth
	to distinguish the different depth for every vlan dev, the same depth of the vlan dev
	could have the same lock_class_key, I import the MAX_LOCK_DEPTH from the include/linux/sched.h,
	I think it is enough here, the lockdep should never exceed that value.

v3->v4: Add a huge array of locking keys will waste static kernel memory and is not a appropriate method,
	we could use _nested() variants to fix the problem, calculate the depth for every vlan dev,
	and use the depth as the subclass for addr_lock_key.

Signed-off-by: Ding Tianhong 
Signed-off-by: David S. Miller

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem

2014-04-17T14:34:22+00:00

ip6_tunnel: use the right netns in ioctl handler

2014-04-16T19:16:02+00:00

Because the netdevice may be in another netns than the i/o netns, we should
use the i/o netns instead of dev_net(dev).

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

sit: use the right netns in ioctl handler

2014-04-16T19:16:02+00:00

Because the netdevice may be in another netns than the i/o netns, we should
use the i/o netns instead of dev_net(dev).

Note that netdev_priv(dev) cannot bu NULL, hence we can remove these useless
checks.

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

ip_tunnel: use the right netns in ioctl handler

2014-04-16T19:16:02+00:00

Because the netdevice may be in another netns than the i/o netns, we should
use the i/o netns instead of dev_net(dev).

The variable 'tunnel' was used only to get 'itn', hence to simplify code I
remove it and use 't' instead.

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

net: use SYSCALL_DEFINEx for sys_recv

2014-04-16T19:15:05+00:00

Make sys_recv a first class citizen by using the SYSCALL_DEFINEx
macro. Besides being cleaner this will also generate meta data
for the system call so tracing tools like ftrace or LTTng can
resolve this system call.

Signed-off-by: Jan Glauber 
Signed-off-by: David S. Miller

ipv4, route: pass 0 instead of LOOPBACK_IFINDEX to fib_validate_source()

2014-04-16T19:05:12+00:00

In my special case, when a packet is redirected from veth0 to lo,
its skb->dev->ifindex would be LOOPBACK_IFINDEX. Meanwhile we
pass the hard-coded LOOPBACK_IFINDEX to fib_validate_source()
in ip_route_input_slow(). This would cause the following check
in fib_validate_source() fail:

            (dev->ifindex != oif || !IN_DEV_TX_REDIRECTS(idev))

when rp_filter is disabeld on loopback. As suggested by Julian,
the caller should pass 0 here so that we will not end up by
calling __fib_validate_source().

Cc: Eric Biederman 
Cc: Julian Anastasov 
Cc: David S. Miller 
Signed-off-by: Cong Wang 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller

ipv4, fib: pass LOOPBACK_IFINDEX instead of 0 to flowi4_iif

2014-04-16T19:05:11+00:00

As suggested by Julian:

	Simply, flowi4_iif must not contain 0, it does not
	look logical to ignore all ip rules with specified iif.

because in fib_rule_match() we do:

        if (rule->iifindex && (rule->iifindex != fl->flowi_iif))
                goto out;

flowi4_iif should be LOOPBACK_IFINDEX by default.

We need to move LOOPBACK_IFINDEX to include/net/flow.h:

1) It is mostly used by flowi_iif

2) Fix the following compile error if we use it in flow.h
by the patches latter:

In file included from include/linux/netfilter.h:277:0,
                 from include/net/netns/netfilter.h:5,
                 from include/net/net_namespace.h:21,
                 from include/linux/netdevice.h:43,
                 from include/linux/icmpv6.h:12,
                 from include/linux/ipv6.h:61,
                 from include/net/ipv6.h:16,
                 from include/linux/sunrpc/clnt.h:27,
                 from include/linux/nfs_fs.h:30,
                 from init/do_mounts.c:32:
include/net/flow.h: In function ‘flowi4_init_output’:
include/net/flow.h:84:32: error: ‘LOOPBACK_IFINDEX’ undeclared (first use in this function)

Cc: Eric Biederman 
Cc: Julian Anastasov 
Cc: David S. Miller 
Signed-off-by: Cong Wang 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller