linux.git/net, branch v4.2-rc7

net: dsa: Do not override PHY interface if already configured

2015-08-12T21:29:50+00:00

In case we need to divert reads/writes using the slave MII bus, we may have
already fetched a valid PHY interface property from Device Tree, and that
mode is used by the PHY driver to make configuration decisions.

If we could not fetch the "phy-mode" property, we will assign p->phy_interface
to PHY_INTERFACE_MODE_NA, such that we can actually check for that condition as
to whether or not we should override the interface value.

Fixes: 19334920eaf7 ("net: dsa: Set valid phy interface type")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth

2015-08-11T21:16:07+00:00

Johan Hedberg says:

====================
pull request: bluetooth 2015-08-11

Here's an important regression fix for the 4.2-rc series that ensures
user space isn't given invalid LTK values. The bug essentially prevents
the encryption of subsequent LE connections, i.e. makes it impossible to
pair devices over LE.

Let me know if there are any issues pulling. Thanks.
====================

Signed-off-by: David S. Miller

inet: fix possible request socket leak

2015-08-11T04:17:45+00:00

In commit b357a364c57c9 ("inet: fix possible panic in
reqsk_queue_unlink()"), I missed fact that tcp_check_req()
can return the listener socket in one case, and that we must
release the request socket refcount or we leak it.

Tested:

 Following packetdrill test template shows the issue

0     socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0    setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0    bind(3, ..., ...) = 0
+0    listen(3, 1) = 0

+0    < S 0:0(0) win 2920 
+0    > S. 0:0(0) ack 1 
+.002 < . 1:1(0) ack 21 win 2920
+0    > R 21:21(0)

Fixes: b357a364c57c9 ("inet: fix possible panic in reqsk_queue_unlink()")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

inet: fix races with reqsk timers

2015-08-11T04:17:29+00:00

reqsk_queue_destroy() and reqsk_queue_unlink() should use
del_timer_sync() instead of del_timer() before calling reqsk_put(),
otherwise we could free a req still used by another cpu.

But before doing so, reqsk_queue_destroy() must release syn_wait_lock
spinlock or risk a dead lock, as reqsk_timer_handler() might
need to take this same spinlock from reqsk_queue_unlink() (called from
inet_csk_reqsk_queue_drop())

Fixes: fa76ce7328b2 ("inet: get rid of central tcp/dccp listener timer")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf

2015-08-11T04:03:25+00:00

Pablo Neira Ayuso says:

====================
Netfilter fixes for net

The following patchset contains five Netfilter fixes for your net tree,
they are:

1) Silence a warning on falling back to vmalloc(). Since 88eab472ec21, we can
   easily hit this warning message, that gets users confused. So let's get rid
   of it.

2) Recently when porting the template object allocation on top of kmalloc to
   fix the netns dependencies between x_tables and conntrack, the error
   checks where left unchanged. Remove IS_ERR() and check for NULL instead.
   Patch from Dan Carpenter.

3) Don't ignore gfp_flags in the new nf_ct_tmpl_alloc() function, from
   Joe Stringer.

4) Fix a crash due to NULL pointer dereference in ip6t_SYNPROXY, patch from
   Phil Sutter.

5) The sequence number of the Syn+ack that is sent from SYNPROXY to clients is
   not adjusted through our NAT infrastructure, as a result the client may
   ignore this TCP packet and TCP flow hangs until the client probes us.  Also
   from Phil Sutter.
====================

Signed-off-by: David S. Miller

ipv6: don't reject link-local nexthop on other interface

2015-08-10T20:29:22+00:00

48ed7b26faa7 ("ipv6: reject locally assigned nexthop addresses") is too
strict; it rejects following corner-case:

ip -6 route add default via fe80::1:2:3 dev eth1

[ where fe80::1:2:3 is assigned to a local interface, but not eth1 ]

Fix this by restricting search to given device if nh is linklocal.

Joint work with Hannes Frederic Sowa.

Fixes: 48ed7b26faa7 ("ipv6: reject locally assigned nexthop addresses")
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller

netlink: make sure -EBUSY won't escape from netlink_insert

2015-08-10T17:59:10+00:00

Linus reports the following deadlock on rtnl_mutex; triggered only
once so far (extract):

[12236.694209] NetworkManager  D 0000000000013b80     0  1047      1 0x00000000
[12236.694218]  ffff88003f902640 0000000000000000 ffffffff815d15a9 0000000000000018
[12236.694224]  ffff880119538000 ffff88003f902640 ffffffff81a8ff84 00000000ffffffff
[12236.694230]  ffffffff81a8ff88 ffff880119c47f00 ffffffff815d133a ffffffff81a8ff80
[12236.694235] Call Trace:
[12236.694250]  [] ? schedule_preempt_disabled+0x9/0x10
[12236.694257]  [] ? schedule+0x2a/0x70
[12236.694263]  [] ? schedule_preempt_disabled+0x9/0x10
[12236.694271]  [] ? __mutex_lock_slowpath+0x7f/0xf0
[12236.694280]  [] ? mutex_lock+0x16/0x30
[12236.694291]  [] ? rtnetlink_rcv+0x10/0x30
[12236.694299]  [] ? netlink_unicast+0xfb/0x180
[12236.694309]  [] ? rtnl_getlink+0x113/0x190
[12236.694319]  [] ? rtnetlink_rcv_msg+0x7a/0x210
[12236.694331]  [] ? sock_has_perm+0x5c/0x70
[12236.694339]  [] ? rtnetlink_rcv+0x30/0x30
[12236.694346]  [] ? netlink_rcv_skb+0x9c/0xc0
[12236.694354]  [] ? rtnetlink_rcv+0x1f/0x30
[12236.694360]  [] ? netlink_unicast+0xfb/0x180
[12236.694367]  [] ? netlink_sendmsg+0x484/0x5d0
[12236.694376]  [] ? __wake_up+0x2f/0x50
[12236.694387]  [] ? sock_sendmsg+0x33/0x40
[12236.694396]  [] ? ___sys_sendmsg+0x22e/0x240
[12236.694405]  [] ? ___sys_recvmsg+0x135/0x1a0
[12236.694415]  [] ? eventfd_write+0x82/0x210
[12236.694423]  [] ? fsnotify+0x32e/0x4c0
[12236.694429]  [] ? wake_up_q+0x60/0x60
[12236.694434]  [] ? __sys_sendmsg+0x39/0x70
[12236.694440]  [] ? entry_SYSCALL_64_fastpath+0x12/0x6a

It seems so far plausible that the recursive call into rtnetlink_rcv()
looks suspicious. One way, where this could trigger is that the senders
NETLINK_CB(skb).portid was wrongly 0 (which is rtnetlink socket), so
the rtnl_getlink() request's answer would be sent to the kernel instead
to the actual user process, thus grabbing rtnl_mutex() twice.

One theory would be that netlink_autobind() triggered via netlink_sendmsg()
internally overwrites the -EBUSY error to 0, but where it is wrongly
originating from __netlink_insert() instead. That would reset the
socket's portid to 0, which is then filled into NETLINK_CB(skb).portid
later on. As commit d470e3b483dc ("[NETLINK]: Fix two socket hashing bugs.")
also puts it, -EBUSY should not be propagated from netlink_insert().

It looks like it's very unlikely to reproduce. We need to trigger the
rhashtable_insert_rehash() handler under a situation where rehashing
currently occurs (one /rare/ way would be to hit ht->elasticity limits
while not filled enough to expand the hashtable, but that would rather
require a specifically crafted bind() sequence with knowledge about
destination slots, seems unlikely). It probably makes sense to guard
__netlink_insert() in any case and remap that error. It was suggested
that EOVERFLOW might be better than an already overloaded ENOMEM.

Reference: http://thread.gmane.org/gmane.linux.network/372676
Reported-by: Linus Torvalds 
Signed-off-by: Daniel Borkmann 
Acked-by: Herbert Xu 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller

netfilter: SYNPROXY: fix sending window update to client

2015-08-10T11:55:07+00:00

Upon receipt of SYNACK from the server, ipt_SYNPROXY first sends back an ACK to
finish the server handshake, then calls nf_ct_seqadj_init() to initiate
sequence number adjustment of forwarded packets to the client and finally sends
a window update to the client to unblock it's TX queue.

Since synproxy_send_client_ack() does not set synproxy_send_tcp()'s nfct
parameter, no sequence number adjustment happens and the client receives the
window update with incorrect sequence number. Depending on client TCP
implementation, this leads to a significant delay (until a window probe is
being sent).

Signed-off-by: Phil Sutter 
Signed-off-by: Pablo Neira Ayuso

netfilter: ip6t_SYNPROXY: fix NULL pointer dereference

2015-08-10T11:54:44+00:00

This happens when networking namespaces are enabled.

Suggested-by: Patrick McHardy 
Signed-off-by: Phil Sutter 
Acked-by: Patrick McHardy 
Signed-off-by: Pablo Neira Ayuso

Merge tag 'batman-adv-fix-for-davem' of git://git.open-mesh.org/linux-merge

2015-08-07T22:51:10+00:00

Antonio Quartulli says:

====================
Included changes:
- prevent DAT from replying on behalf of local clients and confuse L2
  bridges
- fix crash on double list removal of TT objects (tt_local_entry)
- fix crash due to missing NULL checks
- initialize bw values for new GWs objects to prevent memory leak
====================

Signed-off-by: David S. Miller