linux-stable.git/net, branch v4.7.2

netlabel: add address family checks to netlbl_{sock,req}_delattr()

2016-08-20T16:10:58+00:00

commit 0e0e36774081534783aa8eeb9f6fbddf98d3c061 upstream.

It seems risky to always rely on the caller to ensure the socket's
address family is correct before passing it to the NetLabel kAPI,
especially since we see at least one LSM which didn't. Add address
family checks to the *_delattr() functions to help prevent future
problems.

Reported-by: Maninder Singh 
Signed-off-by: Paul Moore 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU

2016-08-20T16:10:54+00:00

commit 23bc6ab0a0912146fd674a0becc758c3162baabc upstream.

When we retrieve imtu value from userspace we should use 16 bit pointer
cast instead of 32 as it's defined that way in headers. Fixes setsockopt
calls on big-endian platforms.

Signed-off-by: Amadeusz Sławiński 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

tcp: consider recv buf for the initial window scale

2016-08-16T07:34:58+00:00

[ Upstream commit f626300a3e776ccc9671b0dd94698fb3aa315966 ]

tcp_select_initial_window() intends to advertise a window
scaling for the maximum possible window size. To do so,
it considers the maximum of net.ipv4.tcp_rmem[2] and
net.core.rmem_max as the only possible upper-bounds.
However, users with CAP_NET_ADMIN can use SO_RCVBUFFORCE
to set the socket's receive buffer size to values
larger than net.ipv4.tcp_rmem[2] and net.core.rmem_max.
Thus, SO_RCVBUFFORCE is effectively ignored by
tcp_select_initial_window().

To fix this, consider the maximum of net.ipv4.tcp_rmem[2],
net.core.rmem_max and socket's initial buffer space.

Fixes: b0573dea1fb3 ("[NET]: Introduce SO_{SND,RCV}BUFFORCE socket options")
Signed-off-by: Soheil Hassas Yeganeh 
Suggested-by: Neal Cardwell 
Acked-by: Neal Cardwell 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sctp: terminate rhashtable walk correctly

2016-08-16T07:34:58+00:00

[ Upstream commit 5fc382d87517707ad77ea4c9c12e2a3fde2c838a ]

I was seeing a lot of these:

    BUG: sleeping function called from invalid context at mm/slab.h:388
    in_atomic(): 0, irqs_disabled(): 0, pid: 14971, name: trinity-c2
    Preemption disabled at:[] rhashtable_walk_start+0x46/0x150

     [] preempt_count_add+0x1fb/0x280
     [] _raw_spin_lock+0x12/0x40
     [] console_unlock+0x2f7/0x930
     [] vprintk_emit+0x2fb/0x520
     [] vprintk_default+0x1a/0x20
     [] printk+0x94/0xb0
     [] print_stack_trace+0xe0/0x170
     [] ___might_sleep+0x3be/0x460
     [] __might_sleep+0x90/0x1a0
     [] kmem_cache_alloc+0x153/0x1e0
     [] rhashtable_walk_init+0xfe/0x2d0
     [] sctp_transport_walk_start+0x1e/0x60
     [] sctp_transport_seq_start+0x4d/0x150
     [] seq_read+0x27b/0x1180
     [] proc_reg_read+0xbc/0x180
     [] __vfs_read+0xdb/0x610
     [] vfs_read+0xea/0x2d0
     [] SyS_pread64+0x11b/0x150
     [] do_syscall_64+0x19c/0x410
     [] return_from_SYSCALL_64+0x0/0x6a
     [] 0xffffffffffffffff

Apparently we always need to call rhashtable_walk_stop(), even when
rhashtable_walk_start() fails:

 * rhashtable_walk_start - Start a hash table walk
 * @iter:       Hash table iterator
 *
 * Start a hash table walk.  Note that we take the RCU lock in all
 * cases including when we return an error.  So you must always call
 * rhashtable_walk_stop to clean up.

otherwise we never call rcu_read_unlock() and we get the splat above.

Fixes: 53fa1036 ("sctp: fix some rhashtable functions using in sctp proc/diag")
See-also: 53fa1036 ("sctp: fix some rhashtable functions using in sctp proc/diag")
See-also: f2dba9c6 ("rhashtable: Introduce rhashtable_walk_*")
Cc: Xin Long 
Cc: Herbert Xu 
Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/irda: fix NULL pointer dereference on memory allocation failure

2016-08-16T07:34:58+00:00

[ Upstream commit d3e6952cfb7ba5f4bfa29d4803ba91f96ce1204d ]

I ran into this:

    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    task: ffff8800b745f2c0 ti: ffff880111740000 task.ti: ffff880111740000
    RIP: 0010:[]  [] irttp_connect_request+0x36/0x710
    RSP: 0018:ffff880111747bb8  EFLAGS: 00010286
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000069dd8358
    RDX: 0000000000000009 RSI: 0000000000000027 RDI: 0000000000000048
    RBP: ffff880111747c00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000069dd8358 R11: 1ffffffff0759723 R12: 0000000000000000
    R13: ffff88011a7e4780 R14: 0000000000000027 R15: 0000000000000000
    FS:  00007fc738404700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc737fdfb10 CR3: 0000000118087000 CR4: 00000000000006e0
    Stack:
     0000000000000200 ffff880111747bd8 ffffffff810ee611 ffff880119f1f220
     ffff880119f1f4f8 ffff880119f1f4f0 ffff88011a7e4780 ffff880119f1f232
     ffff880119f1f220 ffff880111747d58 ffffffff82bca542 0000000000000000
    Call Trace:
     [] irda_connect+0x562/0x1190
     [] SYSC_connect+0x202/0x2a0
     [] SyS_connect+0x9/0x10
     [] do_syscall_64+0x19c/0x410
     [] entry_SYSCALL64_slow_path+0x25/0x25
    Code: 41 89 ca 48 89 e5 41 57 41 56 41 55 41 54 41 89 d7 53 48 89 fb 48 83 c7 48 48 89 fa 41 89 f6 48 c1 ea 03 48 83 ec 20 4c 8b 65 10 <0f> b6 04 02 84 c0 74 08 84 c0 0f 8e 4c 04 00 00 80 7b 48 00 74
    RIP  [] irttp_connect_request+0x36/0x710
     RSP 
    ---[ end trace 4cda2588bc055b30 ]---

The problem is that irda_open_tsap() can fail and leave self->tsap = NULL,
and then irttp_connect_request() almost immediately dereferences it.

Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: fix BH handling on socket backlog

2016-08-16T07:34:58+00:00

[ Upstream commit eefc1b1d105ee4d2ce907833ce675f1e9599b5e3 ]

Now that the backlog processing is called with BH enabled, we have to
disable BH before taking the socket lock via bh_lock_sock() otherwise
it may dead lock:

sctp_backlog_rcv()
                bh_lock_sock(sk);

                if (sock_owned_by_user(sk)) {
                        if (sk_add_backlog(sk, skb, sk->sk_rcvbuf))
                                sctp_chunk_free(chunk);
                        else
                                backloged = 1;
                } else
                        sctp_inq_push(inqueue, chunk);

                bh_unlock_sock(sk);

while sctp_inq_push() was disabling/enabling BH, but enabling BH
triggers pending softirq, which then may try to re-lock the socket in
sctp_rcv().

[  219.187215]  
[  219.187217]  [] _raw_spin_lock+0x20/0x30
[  219.187223]  [] sctp_rcv+0x48c/0xba0 [sctp]
[  219.187225]  [] ? nf_iterate+0x62/0x80
[  219.187226]  [] ip_local_deliver_finish+0x94/0x1e0
[  219.187228]  [] ip_local_deliver+0x6f/0xf0
[  219.187229]  [] ? ip_rcv_finish+0x3b0/0x3b0
[  219.187230]  [] ip_rcv_finish+0xd8/0x3b0
[  219.187232]  [] ip_rcv+0x282/0x3a0
[  219.187233]  [] ? update_curr+0x66/0x180
[  219.187235]  [] __netif_receive_skb_core+0x524/0xa90
[  219.187236]  [] ? update_cfs_shares+0x30/0xf0
[  219.187237]  [] ? __enqueue_entity+0x6c/0x70
[  219.187239]  [] ? enqueue_entity+0x204/0xdf0
[  219.187240]  [] __netif_receive_skb+0x18/0x60
[  219.187242]  [] process_backlog+0x9e/0x140
[  219.187243]  [] net_rx_action+0x22c/0x370
[  219.187245]  [] __do_softirq+0x112/0x2e7
[  219.187247]  [] do_softirq_own_stack+0x1c/0x30
[  219.187247]  
[  219.187248]  [] do_softirq.part.14+0x38/0x40
[  219.187249]  [] __local_bh_enable_ip+0x7d/0x80
[  219.187254]  [] sctp_inq_push+0x68/0x80 [sctp]
[  219.187258]  [] sctp_backlog_rcv+0x151/0x1c0 [sctp]
[  219.187260]  [] __release_sock+0x87/0xf0
[  219.187261]  [] release_sock+0x30/0xa0
[  219.187265]  [] sctp_accept+0x17d/0x210 [sctp]
[  219.187266]  [] ? prepare_to_wait_event+0xf0/0xf0
[  219.187268]  [] inet_accept+0x3c/0x130
[  219.187269]  [] SYSC_accept4+0x103/0x210
[  219.187271]  [] ? _raw_spin_unlock_bh+0x1a/0x20
[  219.187272]  [] ? release_sock+0x8c/0xa0
[  219.187276]  [] ? sctp_inet_listen+0x62/0x1b0 [sctp]
[  219.187277]  [] SyS_accept+0x10/0x20

Fixes: 860fbbc343bf ("sctp: prepare for socket backlog behavior change")
Cc: Eric Dumazet 
Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ipv6: Always leave anycast and multicast groups on link down

2016-08-16T07:34:58+00:00

[ Upstream commit ea06f7176413e2538d13bb85b65387d0917943d9 ]

Default kernel behavior is to delete IPv6 addresses on link
down, which entails deletion of the multicast and the
subnet-router anycast addresses. These deletions do not
happen with sysctl setting to keep global IPv6 addresses on
link down, so every link down/up causes an increment of the
anycast and multicast refcounts. These bogus refcounts may
stop these addrs from being removed on subsequent calls to
delete them. The solution is to leave the groups for the
multicast and subnet anycast on link down for the callflow
when global IPv6 addresses are kept.

Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning 
Acked-by: David Ahern 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: Fix incorrect re-injection of LLDP packets

2016-08-16T07:34:57+00:00

[ Upstream commit baedbe55884c003819f5c8c063ec3d2569414296 ]

Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
returns QUEUE or STOLEN verdict") caused LLDP packets arriving through a
bridge port to be re-injected to the Rx path with skb->dev set to the
bridge device, but this breaks the lldpad daemon.

The lldpad daemon opens a packet socket with protocol set to ETH_P_LLDP
for any valid device on the system, which doesn't not include soft
devices such as bridge and VLAN.

Since packet sockets (ptype_base) are processed in the Rx path after the
Rx handler, LLDP packets with skb->dev set to the bridge device never
reach the lldpad daemon.

Fix this by making the bridge's Rx handler re-inject LLDP packets with
RX_HANDLER_PASS, which effectively restores the behaviour prior to the
mentioned commit.

This means netfilter will never receive LLDP packets coming through a
bridge port, as I don't see a way in which we can have okfn() consume
the packet without breaking existing behaviour. I've already carried out
a similar fix for STP packets in commit 56fae404fb2c ("bridge: Fix
incorrect re-injection of STP packets").

Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
Signed-off-by: Ido Schimmel 
Reviewed-by: Jiri Pirko 
Cc: Florian Westphal 
Cc: John Fastabend 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

udp: use sk_filter_trim_cap for udp{,6}_queue_rcv_skb

2016-08-16T07:34:57+00:00

[ Upstream commit ba66bbe5480a012108958a71cff88b23dce84956 ]

After a612769774a3 ("udp: prevent bugcheck if filter truncates packet
too much"), there followed various other fixes for similar cases such
as f4979fcea7fd ("rose: limit sk_filter trim to payload").

Latter introduced a new helper sk_filter_trim_cap(), where we can pass
the trim limit directly to the socket filter handling. Make use of it
here as well with sizeof(struct udphdr) as lower cap limit and drop the
extra skb->len test in UDP's input path.

Signed-off-by: Daniel Borkmann 
Cc: Willem de Bruijn 
Acked-by: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'ceph-for-4.7-rc8' of git://github.com/ceph/ceph-client

2016-07-24T01:00:31+00:00

Pull ceph fix from Ilya Dryomov:
 "A fix for a long-standing bug in the incremental osdmap handling code
  that caused misdirected requests, tagged for stable"

  The tag is signed with a brand new key - Sage is on vacation and I
  didn't anticipate this"

* tag 'ceph-for-4.7-rc8' of git://github.com/ceph/ceph-client:
  libceph: apply new_state before new_up_client on incrementals