- 06 Apr, 2017 40 commits
-
-
Jon Maxwell authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 45caeaa5 ] As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: #8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . #9 [] tcp_rcv_established at ffffffff81580b64 #10 [] tcp_v4_do_rcv at ffffffff8158b54a #11 [] tcp_v4_rcv at ffffffff8158cd02 #12 [] ip_local_deliver_finish at ffffffff815668f4 #13 [] ip_local_deliver at ffffffff81566bd9 #14 [] ip_rcv_finish at ffffffff8156656d #15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] #21 [] net_rx_action at ffffffff8152bac2 #22 [] __do_softirq at ffffffff81084b4f #23 [] call_softirq at ffffffff8164845c #24 [] do_softirq at ffffffff81016fc5 #25 [] irq_exit at ffffffff81084ee5 #26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)
↩ 225 {↩ 226 ▹ const struct inet_connection_sock *icsk = inet_csk(sk);↩ 227 ▹ const struct dst_entry *dst = __sk_dst_get(sk);↩ 228↩ 229 ▹ return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩ 230 ▹ ▹ (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩ 231 }↩ But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb33206 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <egarver@redhat.com> Cc: Hannes Sowa <hsowa@redhat.com> Signed-off-by:Jon Maxwell <jmaxwell37@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Florian Westphal authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 79e49503 ] ip6_fragment, in case skb has a fraglist, checks if the skb is cloned. If it is, it will move to the 'slow path' and allocates new skbs for each fragment. However, right before entering the slowpath loop, it updates the nexthdr value of the last ipv6 extension header to NEXTHDR_FRAGMENT, to account for the fragment header that will be inserted in the new ipv6-fragment skbs. In case original skb is cloned this munges nexthdr value of another skb. Avoid this by doing the nexthdr update for each of the new fragment skbs separately. This was observed with tcpdump on a bridge device where netfilter ipv6 reassembly is active: tcpdump shows malformed fragment headers as the l4 header (icmpv6, tcp, etc). is decoded as a fragment header. Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Reported-by:
Andreas Karis <akaris@redhat.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Sabrina Dubroca authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 67e19400 ] Commit 27596472 ("ipv6: fix ECMP route replacement") introduced a loop that removes all siblings of an ECMP route that is being replaced. However, this loop doesn't stop when it has replaced siblings, and keeps removing other routes with a higher metric. We also end up triggering the WARN_ON after the loop, because after this nsiblings < 0. Instead, stop the loop when we have taken care of all routes with the same metric as the route being replaced. Reproducer: =========== #!/bin/sh ip netns add ns1 ip netns add ns2 ip -net ns1 link set lo up for x in 0 1 2 ; do ip link add veth$x netns ns2 type veth peer name eth$x netns ns1 ip -net ns1 link set eth$x up ip -net ns2 link set veth$x up done ip -net ns1 -6 r a 2000::/64 nexthop via fe80::0 dev eth0 \ nexthop via fe80::1 dev eth1 nexthop via fe80::2 dev eth2 ip -net ns1 -6 r a 2000::/64 via fe80::42 dev eth0 metric 256 ip -net ns1 -6 r a 2000::/64 via fe80::43 dev eth0 metric 2048 echo "before replace, 3 routes" ip -net ns1 -6 r | grep -v '^fe80\|^ff00' echo ip -net ns1 -6 r c 2000::/64 nexthop via fe80::4 dev eth0 \ nexthop via fe80::5 dev eth1 nexthop via fe80::6 dev eth2 echo "after replace, only 2 routes, metric 2048 is gone" ip -net ns1 -6 r | grep -v '^fe80\|^ff00' Fixes: 27596472 ("ipv6: fix ECMP route replacement") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Acked-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by:
Xin Long <lucien.xin@gmail.com> Reviewed-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
David Ahern authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit e37791ec ] When the mpls_router module is unloaded, mpls routes are deleted but notifications are not sent to userspace leaving userspace caches out of sync. Add the call to mpls_notify_route in mpls_net_exit as routes are freed. Fixes: 0189197f ("mpls: Basic routing support") Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
Etienne Noss authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 52491c76 ] tcf_connmark_init does not check in its configuration if TCA_CONNMARK_PARMS is set, resulting in a null pointer dereference when trying to access it. [501099.043007] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 [501099.043039] IP: [<ffffffffc10c60fb>] tcf_connmark_init+0x8b/0x180 [act_connmark] ... [501099.044334] Call Trace: [501099.044345] [<ffffffffa47270e8>] ? tcf_action_init_1+0x198/0x1b0 [501099.044363] [<ffffffffa47271b0>] ? tcf_action_init+0xb0/0x120 [501099.044380] [<ffffffffa47250a4>] ? tcf_exts_validate+0xc4/0x110 [501099.044398] [<ffffffffc0f5fa97>] ? u32_set_parms+0xa7/0x270 [cls_u32] [501099.044417] [<ffffffffc0f60bf0>] ? u32_change+0x680/0x87b [cls_u32] [501099.044436] [<ffffffffa4725d1d>] ? tc_ctl_tfilter+0x4dd/0x8a0 [501099.044454] [<ffffffffa44a23a1>] ? security_capable+0x41/0x60 [501099.044471] [<ffffffffa470ca01>] ? rtnetlink_rcv_msg+0xe1/0x220 [501099.044490] [<ffffffffa470c920>] ? rtnl_newlink+0x870/0x870 [501099.044507] [<ffffffffa472cc61>] ? netlink_rcv_skb+0xa1/0xc0 [501099.044524] [<ffffffffa47073f4>] ? rtnetlink_rcv+0x24/0x30 [501099.044541] [<ffffffffa472c634>] ? netlink_unicast+0x184/0x230 [501099.044558] [<ffffffffa472c9d8>] ? netlink_sendmsg+0x2f8/0x3b0 [501099.044576] [<ffffffffa46d8880>] ? sock_sendmsg+0x30/0x40 [501099.044592] [<ffffffffa46d8e03>] ? SYSC_sendto+0xd3/0x150 [501099.044608] [<ffffffffa425fda1>] ? __do_page_fault+0x2d1/0x510 [501099.044626] [<ffffffffa47fbd7b>] ? system_call_fast_compare_end+0xc/0x9b Fixes: 22a5dc0e ("net: sched: Introduce connmark action") Signed-off-by:
Étienne Noss <etienne.noss@wifirst.fr> Signed-off-by:
Victorien Molle <victorien.molle@wifirst.fr> Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Dmitry V. Levin authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 745cb7f8 ] Replace MAX_ADDR_LEN with its numeric value to fix the following linux/packet_diag.h userspace compilation error: /usr/include/linux/packet_diag.h:67:17: error: 'MAX_ADDR_LEN' undeclared here (not in a function) __u8 pdmc_addr[MAX_ADDR_LEN]; This is not the first case in the UAPI where the numeric value of MAX_ADDR_LEN is used instead of symbolic one, uapi/linux/if_link.h already does the same: $ grep MAX_ADDR_LEN include/uapi/linux/if_link.h __u8 mac[32]; /* MAX_ADDR_LEN */ There are no UAPI headers besides these two that use MAX_ADDR_LEN. Signed-off-by:
Dmitry V. Levin <ldv@altlinux.org> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
-
David Ahern authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit f7887d40 ] KASAN detected a use-after-free: [ 269.467067] BUG: KASAN: use-after-free in vrf_xmit+0x7f1/0x827 [vrf] at addr ffff8800350a21c0 [ 269.467067] Read of size 4 by task ssh/1879 [ 269.467067] CPU: 1 PID: 1879 Comm: ssh Not tainted 4.10.0+ #249 [ 269.467067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 269.467067] Call Trace: [ 269.467067] dump_stack+0x81/0xb6 [ 269.467067] kasan_object_err+0x21/0x78 [ 269.467067] kasan_report+0x2f7/0x450 [ 269.467067] ? vrf_xmit+0x7f1/0x827 [vrf] [ 269.467067] ? ip_output+0xa4/0xdb [ 269.467067] __asan_load4+0x6b/0x6d [ 269.467067] vrf_xmit+0x7f1/0x827 [vrf] ... Which corresponds to the skb access after xmit handling. Fix by saving skb->len and using the saved value to update stats. Fixes: 193125db ("net: Introduce VRF device driver") Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 62f8f4d9 ] Dmitry reported crashes in DCCP stack [1] Problem here is that when I got rid of listener spinlock, I missed the fact that DCCP stores a complex state in struct dccp_request_sock, while TCP does not. Since multiple cpus could access it at the same time, we need to add protection. [1] BUG: KASAN: use-after-free in dccp_feat_activate_values+0x967/0xab0 net/dccp/feat.c:1541 at addr ffff88003713be68 Read of size 8 by task syz-executor2/8457 CPU: 2 PID: 8457 Comm: syz-executor2 Not tainted 4.10.0-rc7+ #127 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0x292/0x398 lib/dump_stack.c:51 kasan_object_err+0x1c/0x70 mm/kasan/report.c:162 print_address_description mm/kasan/report.c:200 [inline] kasan_report_error mm/kasan/report.c:289 [inline] kasan_report.part.1+0x20e/0x4e0 mm/kasan/report.c:311 kasan_report mm/kasan/report.c:332 [inline] __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:332 dccp_feat_activate_values+0x967/0xab0 net/dccp/feat.c:1541 dccp_create_openreq_child+0x464/0x610 net/dccp/minisocks.c:121 dccp_v6_request_recv_sock+0x1f6/0x1960 net/dccp/ipv6.c:457 dccp_check_req+0x335/0x5a0 net/dccp/minisocks.c:186 dccp_v6_rcv+0x69e/0x1d00 net/dccp/ipv6.c:711 ip6_input_finish+0x46d/0x17a0 net/ipv6/ip6_input.c:279 NF_HOOK include/linux/netfilter.h:257 [inline] ip6_input+0xdb/0x590 net/ipv6/ip6_input.c:322 dst_input include/net/dst.h:507 [inline] ip6_rcv_finish+0x289/0x890 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:257 [inline] ipv6_rcv+0x12ec/0x23d0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228 process_backlog+0xe5/0x6c0 net/core/dev.c:4839 napi_poll net/core/dev.c:5202 [inline] net_rx_action+0xe70/0x1900 net/core/dev.c:5267 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902 </IRQ> do_softirq.part.17+0x1e8/0x230 kernel/softirq.c:328 do_softirq kernel/softirq.c:176 [inline] __local_bh_enable_ip+0x1f2/0x200 kernel/softirq.c:181 local_bh_enable include/linux/bottom_half.h:31 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:971 [inline] ip6_finish_output2+0xbb0/0x23d0 net/ipv6/ip6_output.c:123 ip6_finish_output+0x302/0x960 net/ipv6/ip6_output.c:148 NF_HOOK_COND include/linux/netfilter.h:246 [inline] ip6_output+0x1cb/0x8d0 net/ipv6/ip6_output.c:162 ip6_xmit+0xcdf/0x20d0 include/net/dst.h:501 inet6_csk_xmit+0x320/0x5f0 net/ipv6/inet6_connection_sock.c:179 dccp_transmit_skb+0xb09/0x1120 net/dccp/output.c:141 dccp_xmit_packet+0x215/0x760 net/dccp/output.c:280 dccp_write_xmit+0x168/0x1d0 net/dccp/output.c:362 dccp_sendmsg+0x79c/0xb10 net/dccp/proto.c:796 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744 sock_sendmsg_nosec net/socket.c:635 [inline] sock_sendmsg+0xca/0x110 net/socket.c:645 SYSC_sendto+0x660/0x810 net/socket.c:1687 SyS_sendto+0x40/0x50 net/socket.c:1655 entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP: 0033:0x4458b9 RSP: 002b:00007f8ceb77bb58 EFLAGS: 00000282 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000017 RCX: 00000000004458b9 RDX: 0000000000000023 RSI: 0000000020e60000 RDI: 0000000000000017 RBP: 00000000006e1b90 R08: 00000000200f9fe1 R09: 0000000000000020 R10: 0000000000008010 R11: 0000000000000282 R12: 00000000007080a8 R13: 0000000000000000 R14: 00007f8ceb77c9c0 R15: 00007f8ceb77c700 Object at ffff88003713be50, in cache kmalloc-64 size: 64 Allocated: PID = 8446 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 save_stack+0x43/0xd0 mm/kasan/kasan.c:502 set_track mm/kasan/kasan.c:514 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:605 kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2738 kmalloc include/linux/slab.h:490 [inline] dccp_feat_entry_new+0x214/0x410 net/dccp/feat.c:467 dccp_feat_push_change+0x38/0x220 net/dccp/feat.c:487 __feat_register_sp+0x223/0x2f0 net/dccp/feat.c:741 dccp_feat_propagate_ccid+0x22b/0x2b0 net/dccp/feat.c:949 dccp_feat_server_ccid_dependencies+0x1b3/0x250 net/dccp/feat.c:1012 dccp_make_response+0x1f1/0xc90 net/dccp/output.c:423 dccp_v6_send_response+0x4ec/0xc20 net/dccp/ipv6.c:217 dccp_v6_conn_request+0xaba/0x11b0 net/dccp/ipv6.c:377 dccp_rcv_state_process+0x51e/0x1650 net/dccp/input.c:606 dccp_v6_do_rcv+0x213/0x350 net/dccp/ipv6.c:632 sk_backlog_rcv include/net/sock.h:893 [inline] __sk_receive_skb+0x36f/0xcc0 net/core/sock.c:479 dccp_v6_rcv+0xba5/0x1d00 net/dccp/ipv6.c:742 ip6_input_finish+0x46d/0x17a0 net/ipv6/ip6_input.c:279 NF_HOOK include/linux/netfilter.h:257 [inline] ip6_input+0xdb/0x590 net/ipv6/ip6_input.c:322 dst_input include/net/dst.h:507 [inline] ip6_rcv_finish+0x289/0x890 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:257 [inline] ipv6_rcv+0x12ec/0x23d0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228 process_backlog+0xe5/0x6c0 net/core/dev.c:4839 napi_poll net/core/dev.c:5202 [inline] net_rx_action+0xe70/0x1900 net/core/dev.c:5267 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284 Freed: PID = 15 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 save_stack+0x43/0xd0 mm/kasan/kasan.c:502 set_track mm/kasan/kasan.c:514 [inline] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578 slab_free_hook mm/slub.c:1355 [inline] slab_free_freelist_hook mm/slub.c:1377 [inline] slab_free mm/slub.c:2954 [inline] kfree+0xe8/0x2b0 mm/slub.c:3874 dccp_feat_entry_destructor.part.4+0x48/0x60 net/dccp/feat.c:418 dccp_feat_entry_destructor net/dccp/feat.c:416 [inline] dccp_feat_list_pop net/dccp/feat.c:541 [inline] dccp_feat_activate_values+0x57f/0xab0 net/dccp/feat.c:1543 dccp_create_openreq_child+0x464/0x610 net/dccp/minisocks.c:121 dccp_v6_request_recv_sock+0x1f6/0x1960 net/dccp/ipv6.c:457 dccp_check_req+0x335/0x5a0 net/dccp/minisocks.c:186 dccp_v6_rcv+0x69e/0x1d00 net/dccp/ipv6.c:711 ip6_input_finish+0x46d/0x17a0 net/ipv6/ip6_input.c:279 NF_HOOK include/linux/netfilter.h:257 [inline] ip6_input+0xdb/0x590 net/ipv6/ip6_input.c:322 dst_input include/net/dst.h:507 [inline] ip6_rcv_finish+0x289/0x890 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:257 [inline] ipv6_rcv+0x12ec/0x23d0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228 process_backlog+0xe5/0x6c0 net/core/dev.c:4839 napi_poll net/core/dev.c:5202 [inline] net_rx_action+0xe70/0x1900 net/core/dev.c:5267 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284 Memory state around the buggy address: ffff88003713bd00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88003713bd80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88003713be00: fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb fb ^ Fixes: 079096f1 ("tcp/dccp: install syn_recv requests into ehash table") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Tested-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 9ac25fc0 ] TX skbs do not necessarily hold a reference on skb->sk->sk_refcnt By the time TX completion happens, sk_refcnt might be already 0. sock_hold()/sock_put() would then corrupt critical state, like sk_wmem_alloc and lead to leaks or use after free. Fixes: 62bccb8c ("net-timestamp: Make the clone operation stand-alone from phy timestamping") Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit dd4f1072 ] TX skbs do not necessarily hold a reference on skb->sk->sk_refcnt By the time TX completion happens, sk_refcnt might be already 0. sock_hold()/sock_put() would then corrupt critical state, like sk_wmem_alloc. Fixes: bf7fa551 ("mac80211: Resolve sk_refcnt/sk_wmem_alloc issue in wifi ack path") Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 02b2faaf ] Dmitry Vyukov reported a divide by 0 triggered by syzkaller, exploiting tcp_disconnect() path that was never really considered and/or used before syzkaller ;) I was not able to reproduce the bug, but it seems issues here are the three possible actions that assumed they would never trigger on a listener. 1) tcp_write_timer_handler 2) tcp_delack_timer_handler 3) MTU reduction Only IPv6 MTU reduction was properly testing TCP_CLOSE and TCP_LISTEN states from tcp_v6_mtu_reduced() Signed-off-by:
-
Arnaldo Carvalho de Melo authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit d5afb6f9 ] The code where sk_clone() came from created a new socket and locked it, but then, on the error path didn't unlock it. This problem stayed there for a long while, till b0691c8e ("net: Unlock sock before calling sk_free()") fixed it, but unfortunately the callers of sk_clone() (now sk_clone_locked()) were not audited and the one in dccp_create_openreq_child() remained. Now in the age of the syskaller fuzzer, this was finally uncovered, as reported by Dmitry: ---- 8< ---- I've got the following report while running syzkaller fuzzer on 86292b33 ("Merge branch 'akpm' (patches from Andrew)") [ BUG: held lock freed! ] 4.10.0+ #234 Not tainted ------------------------- syz-executor6/6898 is freeing memory ffff88006286cac0-ffff88006286d3b7, with a lock still held there! (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] spin_lock include/linux/spinlock.h:299 [inline] (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504 5 locks held by syz-executor6/6898: #0: (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff839a34b4>] lock_sock include/net/sock.h:1460 [inline] #0: (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff839a34b4>] inet_stream_connect+0x44/0xa0 net/ipv4/af_inet.c:681 #1: (rcu_read_lock){......}, at: [<ffffffff83bc1c2a>] inet6_csk_xmit+0x12a/0x5d0 net/ipv6/inet6_connection_sock.c:126 #2: (rcu_read_lock){......}, at: [<ffffffff8369b424>] __skb_unlink include/linux/skbuff.h:1767 [inline] #2: (rcu_read_lock){......}, at: [<ffffffff8369b424>] __skb_dequeue include/linux/skbuff.h:1783 [inline] #2: (rcu_read_lock){......}, at: [<ffffffff8369b424>] process_backlog+0x264/0x730 net/core/dev.c:4835 #3: (rcu_read_lock){......}, at: [<ffffffff83aeb5c0>] ip6_input_finish+0x0/0x1700 net/ipv6/ip6_input.c:59 #4: (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] spin_lock include/linux/spinlock.h:299 [inline] #4: (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504 Fix it just like was done by b0691c8e ("net: Unlock sock before calling sk_free()"). Reported-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 13baa00a ] It is now very clear that silly TCP listeners might play with enabling/disabling timestamping while new children are added to their accept queue. Meaning net_enable_timestamp() can be called from BH context while current state of the static key is not enabled. Lets play safe and allow all contexts. The work queue is scheduled only under the problematic cases, which are the static key enable/disable transition, to not slow down critical paths. This extends and improves what we did in commit 5fa8bbda ("net: use a work queue to defer net_disable_timestamp() work") Fixes: b90e5794 ("net: dont call jump_label_dec from irq context") Signed-off-by:
-
Alexander Potapenko authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 540e2894 ] KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of uninitialized memory in packet_bind_spkt(): Acked-by:
Alexander Potapenko <glider@google.com> Signed-off-by:
-
Paul Hüber authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 51fb60eb ] l2tp_ip_backlog_recv may not return -1 if the packet gets dropped. The return value is passed up to ip_local_deliver_finish, which treats negative values as an IP protocol number for resubmission. Signed-off-by:
Paul Hüber <phueber@kernsp.in> Signed-off-by:
-
Julian Anastasov authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 6e28099d ] Restore the lost masking of TOS in input route code to allow ip rules to match it properly. Problem [1] noticed by Shmulik Ladkani <shmulik.ladkani@gmail.com> [1] http://marc.info/?t=137331755300040&r=1&w=2 Fixes: 89aef892 ("ipv4: Delete routing cache.") Signed-off-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
-
David Forster authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 7dcdf941 ] Align vti6 with vti by returning GRE_KEY flag. This enables iproute2 to display tunnel keys on "ip -6 tunnel show" Signed-off-by:
David Forster <dforster@brocade.com> Signed-off-by:
-
Matthias Schiffer authored
BugLink: http://bugs.launchpad.net/bugs/1675789 [ Upstream commit 4e37d691 ] The incorrect check caused an off-by-one error: the maximum VID 0xffffff was unusable. Fixes: d342894c ("vxlan: virtual extensible lan") Signed-off-by:
Matthias Schiffer <mschiffer@universe-factory.net> Acked-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1675789Signed-off-by:
-
Florian Westphal authored
BugLink: http://bugs.launchpad.net/bugs/1675789 commit d1b4c689 upstream. mmapped netlink has a number of unresolved issues: - TX zerocopy support had to be disabled more than a year ago via commit 4682a035 ("netlink: Always copy on mmap TX.") because the content of the mmapped area can change after netlink attribute validation but before message processing. - RX support was implemented mainly to speed up nfqueue dumping packet payload to userspace. However, since commit ae08ce00 ("netfilter: nfnetlink_queue: zero copy support") we avoid one copy with the socket-based interface too (via the skb_zerocopy helper). The other problem is that skbs attached to mmaped netlink socket behave different from normal skbs: - they don't have a shinfo area, so all functions that use skb_shinfo() (e.g. skb_clone) cannot be used. - reserving headroom prevents userspace from seeing the content as it expects message to start at skb->head. See for instance commit aa3a0220 ("netlink: not trim skb for mmaped socket when dump"). - skbs handed e.g. to netlink_ack must have non-NULL skb->sk, else we crash because it needs the sk to check if a tx ring is attached. Also not obvious, leads to non-intuitive bug fixes such as 7c7bdf35 ("netfilter: nfnetlink: use original skbuff when acking batches"). mmaped netlink also didn't play nicely with the skb_zerocopy helper used by nfqueue and openvswitch. Daniel Borkmann fixed this via commit 6bb0fef4 ("netlink, mmap: fix edge-case leakages in nf queue zero-copy")' but at the cost of also needing to provide remaining length to the allocation function. nfqueue also has problems when used with mmaped rx netlink: - mmaped netlink doesn't allow use of nfqueue batch verdict messages. Problem is that in the mmap case, the allocation time also determines the ordering in which the frame will be seen by userspace (A allocating before B means that A is located in earlier ring slot, but this also means that B might get a lower sequence number then A since seqno is decided later. To fix this we would need to extend the spinlocked region to also cover the allocation and message setup which isn't desirable. - nfqueue can now be configured to queue large (GSO) skbs to userspace. Queing GSO packets is faster than having to force a software segmentation in the kernel, so this is a desirable option. However, with a mmap based ring one has to use 64kb per ring slot element, else mmap has to fall back to the socket path (NL_MMAP_STATUS_COPY) for all large packets. To use the mmap interface, userspace not only has to probe for mmap netlink support, it also has to implement a recv/socket receive path in order to handle messages that exceed the size of an rx ring element. Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Ken-ichirou MATSUZAWA <chamaken@gmail.com> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Patrick McHardy <kaber@trash.net> Cc: Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1674635 Hyper-V host emulation of SCSI for virtual DVD device reports SCSI version 0 (UNKNOWN) but is still capable of supporting REPORTLUN. Without this patch, a GEN2 Linux guest on Hyper-V will not boot 4.11 successfully with virtual DVD ROM device. What happens is that the SCSI scan process falls back to doing sequential probing by INQUIRY. But the storvsc driver has a previous workaround that masks/blocks all errors reports from INQUIRY (or MODE_SENSE) commands. This workaround causes the scan to then populate a full set of bogus LUN's on the target and then sends kernel spinning off into a death spiral doing block reads on the non-existent LUNs. By setting the correct blacklist flags, the target with the DVD device is scanned with REPORTLUN and that works correctly. Patch needs to go in current 4.11, it is safe but not necessary in older kernels. Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit f1c635b4) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Jack Morgenstein authored
BugLink: http://bugs.launchpad.net/bugs/1672785 Some Hypervisors detach VFs from VMs by instantly causing an FLR event to be generated for a VF. In the mlx4 case, this will cause that VF's comm channel to be disabled before the VM has an opportunity to invoke the VF device's "shutdown" method. For such Hypervisors, there is a race condition between the VF's shutdown method and its internal-error detection/reset thread. The internal-error detection/reset thread (which runs every 5 seconds) also detects a disabled comm channel. If the internal-error detection/reset flow wins the race, we still get delays (while that flow tries repeatedly to detect comm-channel recovery). The cited commit fixed the command timeout problem when the internal-error detection/reset flow loses the race. This commit avoids the unneeded delays when the internal-error detection/reset flow wins. Fixes: d585df1c ("net/mlx4_core: Avoid command timeouts during VF driver device shutdown") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Reported-by:
Simon Xiao <sixiao@microsoft.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Marcin Niestroj authored
BugLink: https://bugs.launchpad.net/bugs/1676356 Datasheet of each device (lps331ap, lps25h, lps001wp, lps22hb) says that the pressure and temperature data is a 2's complement. I'm sending this the slow way, as negative pressures on these are pretty unusual and the nature of the fixing of multiple device introduction patches will make it hard to apply to older kernels - Jonathan. Fixes: 217494e5 ("iio:pressure: Add STMicroelectronics pressures driver") Fixes: 2f5effcb ("iio: pressure-core: st: Expand and rename LPS331AP's channel descriptor") Fixes: 7885a8ce ("iio: pressure: st: Add support for new LPS001WP pressure sensor") Fixes: e039e2f5 ("iio:st_pressure:initial lps22hb sensor support") Signed-off-by:
Marcin Niestroj <m.niestroj@grinn-global.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> (cherry picked from commit 1b211d48) Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
Gregor Boirie authored
BugLink: https://bugs.launchpad.net/bugs/1676356 Some static channels are explicitly initialized with default values. Remove them to enhance readability. Signed-off-by:
Gregor Boirie <gregor.boirie@parrot.com> Tested-by:
-
Gregor Boirie authored
BugLink: https://bugs.launchpad.net/bugs/1676356 Enable support for triggered buffering of temperature samples. Signed-off-by:
-
Gregor Boirie authored
BugLink: https://bugs.launchpad.net/bugs/1676356 Ensure triggered buffering memory accesses are properly aligned on per channel storagebits boundaries. Signed-off-by:
-
Gregor Boirie authored
BugLink: https://bugs.launchpad.net/bugs/1676356 Use SMBus "block read" protocol only when supported by adapter. Signed-off-by:
-
Linus Walleij authored
BugLink: https://bugs.launchpad.net/bugs/1676356 The current buffer read code tries to optimize reads from the sensor data registers by issuing a single read operation across all the indata registers. This doesn't work: when the LIS331DL accelerometer sensor is configured to open drain, active low interrupt mode, this will just clear the XDA (X-axis data available) bit in the STATUS_REG register (0x27), while YDA, ZDA and even ZYXDA remain set to 1, and the internal logic of the sensor holds the DRDY (INT1) line asserted (the value of the status register is 0xee). If we instead issue one read operation per enabled channel (X, Y, Z) things start working and we can use open drain and active low interrupts. Note that a backported patch fixing this issue will be heading via the fixes branch but changes in this file already in staging-next will make that patch 'look' rather different. The code in here is the correct one when that clash hits. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by:
-
Linus Walleij authored
BugLink: https://bugs.launchpad.net/bugs/1676356 The driver goes to some length to dynamically allocate an array to hold the channel addresses. However no ST sensor has more than three channels (x, y, z at most). Instead of kmalloc():ing and kfree():in the address array, just use a fixed array of three elements. Cc: Giuseppe Barba <giuseppe.barba@st.com> Signed-off-by:
Denis Ciocca <denis.ciocca@st.com> Signed-off-by:
-
Sean Nyekjaer authored
BugLink: https://bugs.launchpad.net/bugs/1676356 Added core support for IIO_VAL_INT in write_raw_get_fmt function. Signed-off-by:
Sean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by:
-
Shashank Sharma authored
BugLink: https://bugs.launchpad.net/bugs/1676747 As per the software design, we are driving lspcon in PCON mode. But while resuming from suspend, lspcon can go in LS mode (which is its default operating mode on power on) This patch adds a resume function for lspcon, which makes sure its operating in PCON mode, post resume. V2: Address review comments from Imre - move lspcon_resume call to encoder->reset() - use early returns Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476455212-27893-6-git-send-email-shashank.sharma@intel.com (cherry picked from commit 910530c0) Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by:
-
Shashank Sharma authored
BugLink: https://bugs.launchpad.net/bugs/1676747 This patch adds initialization code for lspcon. What we are doing here is: - Check if lspcon is configured in VBT for this port - If lspcon is configured, initialize it and configure it as DP port. V2: Addressed Ville's review comments: - Not adding AVI IF functions for LSPCON display now. This part will be added once the dig_port level AVI-IF series gets merged. V3: Rebase V4: Rebase V5: Rebase V6: Rebase Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
-
Shashank Sharma authored
BugLink: https://bugs.launchpad.net/bugs/1676747 Many GEN9 boards come with on-board lspcon cards. Fot these boards, VBT configuration should properly point out if a particular port contains lspcon device, so that driver can initialize it properly. This patch adds a utility function, which checks the VBT flag for lspcon bit, and tells us if a port is configured to have a lspcon device or not. V2: Fixed review comments from Ville - Do not forget PORT_D while checking lspcon for GEN9 V3: Addressed review comments from Rodrigo - Create a HAS_LSPCON() macro for better use case handling. - Do not dump warnings for non-gen-9 platforms, it will be noise. V4: Rebase V5: Rebase V6: Pass dev_priv to HAS_LSPCON() macro Signed-off-by:
-
Shashank Sharma authored
BugLink: https://bugs.launchpad.net/bugs/1676747 This patch adds a new file, to accommodate lspcon support for I915 driver. These functions probe, detect, initialize and configure an on-board lspcon device during the driver init time. Also, this patch adds a small structure for lspcon device, which will provide the runtime status of the device. V2: addressed ville's review comments - Clean the leftover macros from previous patch set V3: Rebase V4: addressed ville's review comments - make internal functions static - remove lspcon_detect_identifier, make it inline with lspcon_probe - remove is_lspcon_active function - remove force check while setting a lspcon mode V5: Rebase V6: Pass dev_priv to IS_GEN9 check Signed-off-by:
Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by:
-
Shashank Sharma authored
BugLink: https://bugs.launchpad.net/bugs/1676747 This patch adds lspcon support in dp_dual_mode helper. lspcon is essentially a dp->hdmi dongle with dual personality. LS mode: It works as a passive dongle, by level shifting DP++ signals to HDMI signals, in LS mode. PCON mode: It works as a protocol converter active dongle in pcon mode, by converting DP++ outputs to HDMI 2.0 outputs. This patch adds support for lspcon detection and mode set switch operations, as a dp dual mode dongle. v2: Addressed review comments from Ville - add adaptor id for lspcon devices (0x08), use it to identify lspcon - change function names old: drm_lspcon_get_current_mode/drm_lspcon_change_mode new: drm_lspcon_get_mode/drm_lspcon_set_mode - change drm_lspcon_get_mode type to int, to match drm_dp_dual_mode_get_tmds_output - change 'err' to 'ret' to match the rest of the functions - remove pointless typecasting during call to dual_mode_read - fix the but while setting value of data, while writing lspcon mode - fix indentation - change mdelay(10) -> msleep(10) - return ETIMEDOUT instead of EFAULT, when lspcon mode change times out - Add an empty line to separate std regs macros and lspcon regs macros Indent bit definition v3: Addressed review comments from Rodrigo - change macro name from DP_DUAL_MODE_TYPE_LSPCON to DP_DUAL_MODE_TYPE_HAS_DPCD for better readability - change macro name from DP_DUAL_MODE_LSPCON_MODE_PCON to DP_DUAL_MODE_LSPCON_MODE_PCON for better readability - add comment for MCA specific offsets like 0x40 and 0x41 - remove DP_DUAL_MODE_REV_TYPE2 check while checking lspcon adapter id v4: Addressed review comments from Ville - Fixed indentation at few places - s/current_mode/mode - s/reqd_mode/mode - remove unnecessary void* cast - remove drm_edid.h from includes - Add a comment for _HAS_DPCD - Fix enum description, for lspcon_mode. v5: Rebase v6: Rebase Signed-off-by:
Dave Airlie <airlied@gmail.com> Acked-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1658633 We must lock the xattr block before calculating or verifying the checksum in order to avoid spurious checksum failures. https://bugzilla.kernel.org/show_bug.cgi?id=193661Reported-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org (backport of upstream commit dac7a4b4) Signed-off-by:
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1675327 Replace bitclock by mclk as PLL source to fix noise in audio output from line-out jack. Signed-off-by:
-
Srinivas Pandruvada authored
BugLink: https://bugs.launchpad.net/bugs/1674390 If the processor supports HWP, enable it by default without checking for the cpu model. This will allow to enable HWP in all supported processors without driver change. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 7791e4aa) Signed-off-by:
Robert Hooker <robert.hooker@canonical.com> Acked-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1672470 Andreas reports kernel oops during rmmod of the br_netfilter module. Hannes debugged the oops down to a NULL rt6info->rt6i_indev. Problem is that br_netfilter has the nasty concept of adding a fake rtable to skb->dst; this happens in a br_netfilter prerouting hook. A second hook (in bridge LOCAL_IN) is supposed to remove these again before the skb is handed up the stack. However, on module unload hooks get unregistered which means an skb could traverse the prerouting hook that attaches the fake_rtable, while the 'fake rtable remove' hook gets removed from the hooklist immediately after. Fixes: 34666d46 ("netfilter: bridge: move br_netfilter out of the core") Reported-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Acked-by:
-
Stefan Bader authored
This should be the last one right now. We already added the dm-service-time alternate load balancer. But some setups may want the slightly different approach dm-queue-length offers. BugLink: https://bugs.launchpad.net/bugs/1673350Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
