From: Greg Kroah-Hartman Date: Fri, 15 Mar 2019 06:20:47 +0000 (-0700) Subject: 5.0-stable patches X-Git-Tag: v5.0.3~20 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3fefb5f647f73005df5ab442ed84cabaf7cf4c02;p=thirdparty%2Fkernel%2Fstable-queue.git 5.0-stable patches added patches: connector-fix-unsafe-usage-of-real_parent.patch fou-fou6-avoid-uninit-value-in-gue_err-and-gue6_err.patch gro_cells-make-sure-device-is-up-in-gro_cells_receive.patch ipv4-route-fail-early-when-inet-dev-is-missing.patch l2tp-fix-infoleak-in-l2tp_ip6_recvmsg.patch lan743x-fix-rx-kernel-panic.patch lan743x-fix-tx-stall-issue.patch net-dsa-mv88e6xxx-set-correct-interface-mode-for-cpu-dsa-ports.patch net-hns3-add-dma_rmb-for-rx-description.patch net-hns3-fix-to-stop-multiple-hns-reset-due-to-the-aer-changes.patch net-hsr-fix-memory-leak-in-hsr_dev_finalize.patch net-hsr-fix-possible-crash-in-add_timer.patch net-mlx4_core-fix-locking-in-sriov-mode-when-switching-between-events-and-polling.patch net-mlx4_core-fix-qp-mtt-size-calculation.patch net-mlx4_core-fix-reset-flow-when-in-command-polling-mode.patch net-sched-flower-insert-new-filter-to-idr-after-setting-its-mask.patch net-sit-fix-ubsan-undefined-behaviour-in-check_6rd.patch net-x25-fix-use-after-free-in-x25_device_event.patch net-x25-reset-state-in-x25_connect.patch pptp-dst_release-sk_dst_cache-in-pptp_sock_destruct.patch ravb-decrease-txfifo-depth-of-q3-and-q2-to-one.patch route-set-the-deleted-fnhe-fnhe_daddr-to-0-in-ip_del_fnhe-to-fix-a-race.patch rxrpc-fix-client-call-queueing-waiting-for-channel.patch sctp-remove-sched-init-from-sctp_stream_init.patch tcp-do-not-report-tcp_cm_inq-of-0-for-closed-connections.patch tcp-don-t-access-tcp_skb_cb-before-initializing-it.patch tcp-handle-inet_csk_reqsk_queue_add-failures.patch vsock-virtio-fix-kernel-panic-from-virtio_transport_reset_no_sock.patch vxlan-fix-gro-cells-race-condition-between-receive-and-link-delete.patch vxlan-test-dev-flags-iff_up-before-calling-gro_cells_receive.patch --- diff --git a/queue-5.0/connector-fix-unsafe-usage-of-real_parent.patch b/queue-5.0/connector-fix-unsafe-usage-of-real_parent.patch new file mode 100644 index 00000000000..b8d8dd93366 --- /dev/null +++ b/queue-5.0/connector-fix-unsafe-usage-of-real_parent.patch @@ -0,0 +1,187 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Li RongQing +Date: Wed, 6 Mar 2019 14:46:27 +0800 +Subject: connector: fix unsafe usage of ->real_parent + +From: Li RongQing + +[ Upstream commit 6d2b0f02f5a07a4bf02e4cbc90d7eaa85cac2986 ] + +proc_exit_connector() uses ->real_parent lockless. This is not +safe that its parent can go away at any moment, so use RCU to +protect it, and ensure that this task is not released. + +[ 747.624551] ================================================================== +[ 747.632946] BUG: KASAN: use-after-free in proc_exit_connector+0x1f7/0x310 +[ 747.640686] Read of size 4 at addr ffff88a0276988e0 by task sshd/2882 +[ 747.648032] +[ 747.649804] CPU: 11 PID: 2882 Comm: sshd Tainted: G E 4.19.26-rc2 #11 +[ 747.658629] Hardware name: IBM x3550M4 -[7914OFV]-/00AM544, BIOS -[D7E142BUS-1.71]- 07/31/2014 +[ 747.668419] Call Trace: +[ 747.671269] dump_stack+0xf0/0x19b +[ 747.675186] ? show_regs_print_info+0x5/0x5 +[ 747.679988] ? kmsg_dump_rewind_nolock+0x59/0x59 +[ 747.685302] print_address_description+0x6a/0x270 +[ 747.691162] kasan_report+0x258/0x380 +[ 747.695835] ? proc_exit_connector+0x1f7/0x310 +[ 747.701402] proc_exit_connector+0x1f7/0x310 +[ 747.706767] ? proc_coredump_connector+0x2d0/0x2d0 +[ 747.712715] ? _raw_write_unlock_irq+0x29/0x50 +[ 747.718270] ? _raw_write_unlock_irq+0x29/0x50 +[ 747.723820] ? ___preempt_schedule+0x16/0x18 +[ 747.729193] ? ___preempt_schedule+0x16/0x18 +[ 747.734574] do_exit+0xa11/0x14f0 +[ 747.738880] ? mm_update_next_owner+0x590/0x590 +[ 747.744525] ? debug_show_all_locks+0x3c0/0x3c0 +[ 747.761448] ? ktime_get_coarse_real_ts64+0xeb/0x1c0 +[ 747.767589] ? lockdep_hardirqs_on+0x1a6/0x290 +[ 747.773154] ? check_chain_key+0x139/0x1f0 +[ 747.778345] ? check_flags.part.35+0x240/0x240 +[ 747.783908] ? __lock_acquire+0x2300/0x2300 +[ 747.789171] ? _raw_spin_unlock_irqrestore+0x59/0x70 +[ 747.795316] ? _raw_spin_unlock_irqrestore+0x59/0x70 +[ 747.801457] ? do_raw_spin_unlock+0x10f/0x1e0 +[ 747.806914] ? do_raw_spin_trylock+0x120/0x120 +[ 747.812481] ? preempt_count_sub+0x14/0xc0 +[ 747.817645] ? _raw_spin_unlock+0x2e/0x50 +[ 747.822708] ? __handle_mm_fault+0x12db/0x1fa0 +[ 747.828367] ? __pmd_alloc+0x2d0/0x2d0 +[ 747.833143] ? check_noncircular+0x50/0x50 +[ 747.838309] ? match_held_lock+0x7f/0x340 +[ 747.843380] ? check_noncircular+0x50/0x50 +[ 747.848561] ? handle_mm_fault+0x21a/0x5f0 +[ 747.853730] ? check_flags.part.35+0x240/0x240 +[ 747.859290] ? check_chain_key+0x139/0x1f0 +[ 747.864474] ? __do_page_fault+0x40f/0x760 +[ 747.869655] ? __audit_syscall_entry+0x4b/0x1f0 +[ 747.875319] ? syscall_trace_enter+0x1d5/0x7b0 +[ 747.880877] ? trace_raw_output_preemptirq_template+0x90/0x90 +[ 747.887895] ? trace_raw_output_sys_exit+0x80/0x80 +[ 747.893860] ? up_read+0x3b/0x90 +[ 747.898142] ? stop_critical_timings+0x260/0x260 +[ 747.903909] do_group_exit+0xe0/0x1c0 +[ 747.908591] ? __x64_sys_exit+0x30/0x30 +[ 747.913460] ? trace_raw_output_preemptirq_template+0x90/0x90 +[ 747.920485] ? tracer_hardirqs_on+0x270/0x270 +[ 747.925956] __x64_sys_exit_group+0x28/0x30 +[ 747.931214] do_syscall_64+0x117/0x400 +[ 747.935988] ? syscall_return_slowpath+0x2f0/0x2f0 +[ 747.941931] ? trace_hardirqs_off_thunk+0x1a/0x1c +[ 747.947788] ? trace_hardirqs_on_caller+0x1d0/0x1d0 +[ 747.953838] ? lockdep_sys_exit+0x16/0x8e +[ 747.958915] ? trace_hardirqs_off_thunk+0x1a/0x1c +[ 747.964784] entry_SYSCALL_64_after_hwframe+0x49/0xbe +[ 747.971021] RIP: 0033:0x7f572f154c68 +[ 747.975606] Code: Bad RIP value. +[ 747.979791] RSP: 002b:00007ffed2dfaa58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 +[ 747.989324] RAX: ffffffffffffffda RBX: 00007f572f431840 RCX: 00007f572f154c68 +[ 747.997910] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 +[ 748.006495] RBP: 0000000000000001 R08: 00000000000000e7 R09: fffffffffffffee0 +[ 748.015079] R10: 00007f572f4387e8 R11: 0000000000000246 R12: 00007f572f431840 +[ 748.023664] R13: 000055a7f90f2c50 R14: 000055a7f96e2310 R15: 000055a7f96e2310 +[ 748.032287] +[ 748.034509] Allocated by task 2300: +[ 748.038982] kasan_kmalloc+0xa0/0xd0 +[ 748.043562] kmem_cache_alloc_node+0xf5/0x2e0 +[ 748.049018] copy_process+0x1781/0x4790 +[ 748.053884] _do_fork+0x166/0x9a0 +[ 748.058163] do_syscall_64+0x117/0x400 +[ 748.062943] entry_SYSCALL_64_after_hwframe+0x49/0xbe +[ 748.069180] +[ 748.071405] Freed by task 15395: +[ 748.075591] __kasan_slab_free+0x130/0x180 +[ 748.080752] kmem_cache_free+0xc2/0x310 +[ 748.085619] free_task+0xea/0x130 +[ 748.089901] __put_task_struct+0x177/0x230 +[ 748.095063] finish_task_switch+0x51b/0x5d0 +[ 748.100315] __schedule+0x506/0xfa0 +[ 748.104791] schedule+0xca/0x260 +[ 748.108978] futex_wait_queue_me+0x27e/0x420 +[ 748.114333] futex_wait+0x251/0x550 +[ 748.118814] do_futex+0x75b/0xf80 +[ 748.123097] __x64_sys_futex+0x231/0x2a0 +[ 748.128065] do_syscall_64+0x117/0x400 +[ 748.132835] entry_SYSCALL_64_after_hwframe+0x49/0xbe +[ 748.139066] +[ 748.141289] The buggy address belongs to the object at ffff88a027698000 +[ 748.141289] which belongs to the cache task_struct of size 12160 +[ 748.156589] The buggy address is located 2272 bytes inside of +[ 748.156589] 12160-byte region [ffff88a027698000, ffff88a02769af80) +[ 748.171114] The buggy address belongs to the page: +[ 748.177055] page:ffffea00809da600 count:1 mapcount:0 mapping:ffff888107d01e00 index:0x0 compound_mapcount: 0 +[ 748.189136] flags: 0x57ffffc0008100(slab|head) +[ 748.194688] raw: 0057ffffc0008100 ffffea00809a3200 0000000300000003 ffff888107d01e00 +[ 748.204424] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 +[ 748.214146] page dumped because: kasan: bad access detected +[ 748.220976] +[ 748.223197] Memory state around the buggy address: +[ 748.229128] ffff88a027698780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 748.238271] ffff88a027698800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 748.247414] >ffff88a027698880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 748.256564] ^ +[ 748.264267] ffff88a027698900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 748.273493] ffff88a027698980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 748.282630] ================================================================== + +Fixes: b086ff87251b4a4 ("connector: add parent pid and tgid to coredump and exit events") +Signed-off-by: Zhang Yu +Signed-off-by: Li RongQing +Acked-by: Evgeniy Polyakov +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/connector/cn_proc.c | 22 ++++++++++++++++++---- + 1 file changed, 18 insertions(+), 4 deletions(-) + +--- a/drivers/connector/cn_proc.c ++++ b/drivers/connector/cn_proc.c +@@ -250,6 +250,7 @@ void proc_coredump_connector(struct task + { + struct cn_msg *msg; + struct proc_event *ev; ++ struct task_struct *parent; + __u8 buffer[CN_PROC_MSG_SIZE] __aligned(8); + + if (atomic_read(&proc_event_num_listeners) < 1) +@@ -262,8 +263,14 @@ void proc_coredump_connector(struct task + ev->what = PROC_EVENT_COREDUMP; + ev->event_data.coredump.process_pid = task->pid; + ev->event_data.coredump.process_tgid = task->tgid; +- ev->event_data.coredump.parent_pid = task->real_parent->pid; +- ev->event_data.coredump.parent_tgid = task->real_parent->tgid; ++ ++ rcu_read_lock(); ++ if (pid_alive(task)) { ++ parent = rcu_dereference(task->real_parent); ++ ev->event_data.coredump.parent_pid = parent->pid; ++ ev->event_data.coredump.parent_tgid = parent->tgid; ++ } ++ rcu_read_unlock(); + + memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id)); + msg->ack = 0; /* not used */ +@@ -276,6 +283,7 @@ void proc_exit_connector(struct task_str + { + struct cn_msg *msg; + struct proc_event *ev; ++ struct task_struct *parent; + __u8 buffer[CN_PROC_MSG_SIZE] __aligned(8); + + if (atomic_read(&proc_event_num_listeners) < 1) +@@ -290,8 +298,14 @@ void proc_exit_connector(struct task_str + ev->event_data.exit.process_tgid = task->tgid; + ev->event_data.exit.exit_code = task->exit_code; + ev->event_data.exit.exit_signal = task->exit_signal; +- ev->event_data.exit.parent_pid = task->real_parent->pid; +- ev->event_data.exit.parent_tgid = task->real_parent->tgid; ++ ++ rcu_read_lock(); ++ if (pid_alive(task)) { ++ parent = rcu_dereference(task->real_parent); ++ ev->event_data.exit.parent_pid = parent->pid; ++ ev->event_data.exit.parent_tgid = parent->tgid; ++ } ++ rcu_read_unlock(); + + memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id)); + msg->ack = 0; /* not used */ diff --git a/queue-5.0/fou-fou6-avoid-uninit-value-in-gue_err-and-gue6_err.patch b/queue-5.0/fou-fou6-avoid-uninit-value-in-gue_err-and-gue6_err.patch new file mode 100644 index 00000000000..0fd2c997a92 --- /dev/null +++ b/queue-5.0/fou-fou6-avoid-uninit-value-in-gue_err-and-gue6_err.patch @@ -0,0 +1,165 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Eric Dumazet +Date: Wed, 6 Mar 2019 10:41:00 -0800 +Subject: fou, fou6: avoid uninit-value in gue_err() and gue6_err() + +From: Eric Dumazet + +[ Upstream commit 5355ed6388e23b69a00d48398a68d022135e6486 ] + +My prior commit missed the fact that these functions +were using udp_hdr() (aka skb_transport_header()) +to get access to GUE header. + +Since pskb_transport_may_pull() does not exist yet, we have to add +transport_offset to our pskb_may_pull() calls. + +BUG: KMSAN: uninit-value in gue_err+0x514/0xfa0 net/ipv4/fou.c:1032 +CPU: 1 PID: 10648 Comm: syz-executor.1 Not tainted 5.0.0+ #11 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 +Call Trace: + + __dump_stack lib/dump_stack.c:77 [inline] + dump_stack+0x173/0x1d0 lib/dump_stack.c:113 + kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:600 + __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313 + gue_err+0x514/0xfa0 net/ipv4/fou.c:1032 + __udp4_lib_err_encap_no_sk net/ipv4/udp.c:571 [inline] + __udp4_lib_err_encap net/ipv4/udp.c:626 [inline] + __udp4_lib_err+0x12e6/0x1d40 net/ipv4/udp.c:665 + udp_err+0x74/0x90 net/ipv4/udp.c:737 + icmp_socket_deliver net/ipv4/icmp.c:767 [inline] + icmp_unreach+0xb65/0x1070 net/ipv4/icmp.c:884 + icmp_rcv+0x11a1/0x1950 net/ipv4/icmp.c:1066 + ip_protocol_deliver_rcu+0x584/0xbb0 net/ipv4/ip_input.c:208 + ip_local_deliver_finish net/ipv4/ip_input.c:234 [inline] + NF_HOOK include/linux/netfilter.h:289 [inline] + ip_local_deliver+0x624/0x7b0 net/ipv4/ip_input.c:255 + dst_input include/net/dst.h:450 [inline] + ip_rcv_finish net/ipv4/ip_input.c:414 [inline] + NF_HOOK include/linux/netfilter.h:289 [inline] + ip_rcv+0x6bd/0x740 net/ipv4/ip_input.c:524 + __netif_receive_skb_one_core net/core/dev.c:4973 [inline] + __netif_receive_skb net/core/dev.c:5083 [inline] + process_backlog+0x756/0x10e0 net/core/dev.c:5923 + napi_poll net/core/dev.c:6346 [inline] + net_rx_action+0x78b/0x1a60 net/core/dev.c:6412 + __do_softirq+0x53f/0x93a kernel/softirq.c:293 + invoke_softirq kernel/softirq.c:375 [inline] + irq_exit+0x214/0x250 kernel/softirq.c:416 + exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:536 + smp_apic_timer_interrupt+0x48/0x70 arch/x86/kernel/apic/apic.c:1064 + apic_timer_interrupt+0x2e/0x40 arch/x86/entry/entry_64.S:814 + +RIP: 0010:finish_lock_switch+0x2b/0x40 kernel/sched/core.c:2597 +Code: 48 89 e5 53 48 89 fb e8 63 e7 95 00 8b b8 88 0c 00 00 48 8b 00 48 85 c0 75 12 48 89 df e8 dd db 95 00 c6 00 00 c6 03 00 fb 5b <5d> c3 e8 4e e6 95 00 eb e7 66 90 66 2e 0f 1f 84 00 00 00 00 00 55 +RSP: 0018:ffff888081a0fc80 EFLAGS: 00000296 ORIG_RAX: ffffffffffffff13 +RAX: ffff88821fd6bd80 RBX: ffff888027898000 RCX: ccccccccccccd000 +RDX: ffff88821fca8d80 RSI: ffff888000000000 RDI: 00000000000004a0 +RBP: ffff888081a0fc80 R08: 0000000000000002 R09: ffff888081a0fb08 +R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 +R13: ffff88811130e388 R14: ffff88811130da00 R15: ffff88812fdb7d80 + finish_task_switch+0xfc/0x2d0 kernel/sched/core.c:2698 + context_switch kernel/sched/core.c:2851 [inline] + __schedule+0x6cc/0x800 kernel/sched/core.c:3491 + schedule+0x15b/0x240 kernel/sched/core.c:3535 + freezable_schedule include/linux/freezer.h:172 [inline] + do_nanosleep+0x2ba/0x980 kernel/time/hrtimer.c:1679 + hrtimer_nanosleep kernel/time/hrtimer.c:1733 [inline] + __do_sys_nanosleep kernel/time/hrtimer.c:1767 [inline] + __se_sys_nanosleep+0x746/0x960 kernel/time/hrtimer.c:1754 + __x64_sys_nanosleep+0x3e/0x60 kernel/time/hrtimer.c:1754 + do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 + entry_SYSCALL_64_after_hwframe+0x63/0xe7 +RIP: 0033:0x4855a0 +Code: 00 00 48 c7 c0 d4 ff ff ff 64 c7 00 16 00 00 00 31 c0 eb be 66 0f 1f 44 00 00 83 3d b1 11 5d 00 00 75 14 b8 23 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 04 e2 f8 ff c3 48 83 ec 08 e8 3a 55 fd ff +RSP: 002b:0000000000a4fd58 EFLAGS: 00000246 ORIG_RAX: 0000000000000023 +RAX: ffffffffffffffda RBX: 0000000000085780 RCX: 00000000004855a0 +RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000a4fd60 +RBP: 00000000000007ec R08: 0000000000000001 R09: 0000000000ceb940 +R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008 +R13: 0000000000a4fdb0 R14: 0000000000085711 R15: 0000000000a4fdc0 + +Uninit was created at: + kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline] + kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:159 + kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176 + kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185 + slab_post_alloc_hook mm/slab.h:445 [inline] + slab_alloc_node mm/slub.c:2773 [inline] + __kmalloc_node_track_caller+0xe9e/0xff0 mm/slub.c:4398 + __kmalloc_reserve net/core/skbuff.c:140 [inline] + __alloc_skb+0x309/0xa20 net/core/skbuff.c:208 + alloc_skb include/linux/skbuff.h:1012 [inline] + alloc_skb_with_frags+0x186/0xa60 net/core/skbuff.c:5287 + sock_alloc_send_pskb+0xafd/0x10a0 net/core/sock.c:2091 + sock_alloc_send_skb+0xca/0xe0 net/core/sock.c:2108 + __ip_append_data+0x34cd/0x5000 net/ipv4/ip_output.c:998 + ip_append_data+0x324/0x480 net/ipv4/ip_output.c:1220 + icmp_push_reply+0x23d/0x7e0 net/ipv4/icmp.c:375 + __icmp_send+0x2ea3/0x30f0 net/ipv4/icmp.c:737 + icmp_send include/net/icmp.h:47 [inline] + ipv4_link_failure+0x6d/0x230 net/ipv4/route.c:1190 + dst_link_failure include/net/dst.h:427 [inline] + arp_error_report+0x106/0x1a0 net/ipv4/arp.c:297 + neigh_invalidate+0x359/0x8e0 net/core/neighbour.c:992 + neigh_timer_handler+0xdf2/0x1280 net/core/neighbour.c:1078 + call_timer_fn+0x285/0x600 kernel/time/timer.c:1325 + expire_timers kernel/time/timer.c:1362 [inline] + __run_timers+0xdb4/0x11d0 kernel/time/timer.c:1681 + run_timer_softirq+0x2e/0x50 kernel/time/timer.c:1694 + __do_softirq+0x53f/0x93a kernel/softirq.c:293 + +Fixes: 26fc181e6cac ("fou, fou6: do not assume linear skbs") +Signed-off-by: Eric Dumazet +Reported-by: syzbot +Cc: Stefano Brivio +Cc: Sabrina Dubroca +Acked-by: Stefano Brivio +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/fou.c | 4 ++-- + net/ipv6/fou6.c | 4 ++-- + 2 files changed, 4 insertions(+), 4 deletions(-) + +--- a/net/ipv4/fou.c ++++ b/net/ipv4/fou.c +@@ -1024,7 +1024,7 @@ static int gue_err(struct sk_buff *skb, + int ret; + + len = sizeof(struct udphdr) + sizeof(struct guehdr); +- if (!pskb_may_pull(skb, len)) ++ if (!pskb_may_pull(skb, transport_offset + len)) + return -EINVAL; + + guehdr = (struct guehdr *)&udp_hdr(skb)[1]; +@@ -1059,7 +1059,7 @@ static int gue_err(struct sk_buff *skb, + + optlen = guehdr->hlen << 2; + +- if (!pskb_may_pull(skb, len + optlen)) ++ if (!pskb_may_pull(skb, transport_offset + len + optlen)) + return -EINVAL; + + guehdr = (struct guehdr *)&udp_hdr(skb)[1]; +--- a/net/ipv6/fou6.c ++++ b/net/ipv6/fou6.c +@@ -94,7 +94,7 @@ static int gue6_err(struct sk_buff *skb, + int ret; + + len = sizeof(struct udphdr) + sizeof(struct guehdr); +- if (!pskb_may_pull(skb, len)) ++ if (!pskb_may_pull(skb, transport_offset + len)) + return -EINVAL; + + guehdr = (struct guehdr *)&udp_hdr(skb)[1]; +@@ -129,7 +129,7 @@ static int gue6_err(struct sk_buff *skb, + + optlen = guehdr->hlen << 2; + +- if (!pskb_may_pull(skb, len + optlen)) ++ if (!pskb_may_pull(skb, transport_offset + len + optlen)) + return -EINVAL; + + guehdr = (struct guehdr *)&udp_hdr(skb)[1]; diff --git a/queue-5.0/gro_cells-make-sure-device-is-up-in-gro_cells_receive.patch b/queue-5.0/gro_cells-make-sure-device-is-up-in-gro_cells_receive.patch new file mode 100644 index 00000000000..efa7502e402 --- /dev/null +++ b/queue-5.0/gro_cells-make-sure-device-is-up-in-gro_cells_receive.patch @@ -0,0 +1,130 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Eric Dumazet +Date: Sun, 10 Mar 2019 10:39:37 -0700 +Subject: gro_cells: make sure device is up in gro_cells_receive() + +From: Eric Dumazet + +[ Upstream commit 2a5ff07a0eb945f291e361aa6f6becca8340ba46 ] + +We keep receiving syzbot reports [1] that show that tunnels do not play +the rcu/IFF_UP rules properly. + +At device dismantle phase, gro_cells_destroy() will be called +only after a full rcu grace period is observed after IFF_UP +has been cleared. + +This means that IFF_UP needs to be tested before queueing packets +into netif_rx() or gro_cells. + +This patch implements the test in gro_cells_receive() because +too many callers do not seem to bother enough. + +[1] +BUG: unable to handle kernel paging request at fffff4ca0b9ffffe +PGD 0 P4D 0 +Oops: 0000 [#1] PREEMPT SMP KASAN +CPU: 0 PID: 21 Comm: kworker/u4:1 Not tainted 5.0.0+ #97 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 +Workqueue: netns cleanup_net +RIP: 0010:__skb_unlink include/linux/skbuff.h:1929 [inline] +RIP: 0010:__skb_dequeue include/linux/skbuff.h:1945 [inline] +RIP: 0010:__skb_queue_purge include/linux/skbuff.h:2656 [inline] +RIP: 0010:gro_cells_destroy net/core/gro_cells.c:89 [inline] +RIP: 0010:gro_cells_destroy+0x19d/0x360 net/core/gro_cells.c:78 +Code: 03 42 80 3c 20 00 0f 85 53 01 00 00 48 8d 7a 08 49 8b 47 08 49 c7 07 00 00 00 00 48 89 f9 49 c7 47 08 00 00 00 00 48 c1 e9 03 <42> 80 3c 21 00 0f 85 10 01 00 00 48 89 c1 48 89 42 08 48 c1 e9 03 +RSP: 0018:ffff8880aa3f79a8 EFLAGS: 00010a02 +RAX: 00ffffffffffffe8 RBX: ffffe8ffffc64b70 RCX: 1ffff8ca0b9ffffe +RDX: ffffc6505cffffe8 RSI: ffffffff858410ca RDI: ffffc6505cfffff0 +RBP: ffff8880aa3f7a08 R08: ffff8880aa3e8580 R09: fffffbfff1263645 +R10: fffffbfff1263644 R11: ffffffff8931b223 R12: dffffc0000000000 +R13: 0000000000000000 R14: ffffe8ffffc64b80 R15: ffffe8ffffc64b75 +kobject: 'loop2' (000000004bd7d84a): kobject_uevent_env +FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: fffff4ca0b9ffffe CR3: 0000000094941000 CR4: 00000000001406f0 +Call Trace: +kobject: 'loop2' (000000004bd7d84a): fill_kobj_path: path = '/devices/virtual/block/loop2' + ip_tunnel_dev_free+0x19/0x60 net/ipv4/ip_tunnel.c:1010 + netdev_run_todo+0x51c/0x7d0 net/core/dev.c:8970 + rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:116 + ip_tunnel_delete_nets+0x423/0x5f0 net/ipv4/ip_tunnel.c:1124 + vti_exit_batch_net+0x23/0x30 net/ipv4/ip_vti.c:495 + ops_exit_list.isra.0+0x105/0x160 net/core/net_namespace.c:156 + cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551 + process_one_work+0x98e/0x1790 kernel/workqueue.c:2173 + worker_thread+0x98/0xe40 kernel/workqueue.c:2319 + kthread+0x357/0x430 kernel/kthread.c:246 + ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 +Modules linked in: +CR2: fffff4ca0b9ffffe + [ end trace 513fc9c1338d1cb3 ] +RIP: 0010:__skb_unlink include/linux/skbuff.h:1929 [inline] +RIP: 0010:__skb_dequeue include/linux/skbuff.h:1945 [inline] +RIP: 0010:__skb_queue_purge include/linux/skbuff.h:2656 [inline] +RIP: 0010:gro_cells_destroy net/core/gro_cells.c:89 [inline] +RIP: 0010:gro_cells_destroy+0x19d/0x360 net/core/gro_cells.c:78 +Code: 03 42 80 3c 20 00 0f 85 53 01 00 00 48 8d 7a 08 49 8b 47 08 49 c7 07 00 00 00 00 48 89 f9 49 c7 47 08 00 00 00 00 48 c1 e9 03 <42> 80 3c 21 00 0f 85 10 01 00 00 48 89 c1 48 89 42 08 48 c1 e9 03 +RSP: 0018:ffff8880aa3f79a8 EFLAGS: 00010a02 +RAX: 00ffffffffffffe8 RBX: ffffe8ffffc64b70 RCX: 1ffff8ca0b9ffffe +RDX: ffffc6505cffffe8 RSI: ffffffff858410ca RDI: ffffc6505cfffff0 +RBP: ffff8880aa3f7a08 R08: ffff8880aa3e8580 R09: fffffbfff1263645 +R10: fffffbfff1263644 R11: ffffffff8931b223 R12: dffffc0000000000 +kobject: 'loop3' (00000000e4ee57a6): kobject_uevent_env +R13: 0000000000000000 R14: ffffe8ffffc64b80 R15: ffffe8ffffc64b75 +FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: fffff4ca0b9ffffe CR3: 0000000094941000 CR4: 00000000001406f0 + +Fixes: c9e6bc644e55 ("net: add gro_cells infrastructure") +Signed-off-by: Eric Dumazet +Reported-by: syzbot +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/core/gro_cells.c | 22 ++++++++++++++++++---- + 1 file changed, 18 insertions(+), 4 deletions(-) + +--- a/net/core/gro_cells.c ++++ b/net/core/gro_cells.c +@@ -13,22 +13,36 @@ int gro_cells_receive(struct gro_cells * + { + struct net_device *dev = skb->dev; + struct gro_cell *cell; ++ int res; + +- if (!gcells->cells || skb_cloned(skb) || netif_elide_gro(dev)) +- return netif_rx(skb); ++ rcu_read_lock(); ++ if (unlikely(!(dev->flags & IFF_UP))) ++ goto drop; ++ ++ if (!gcells->cells || skb_cloned(skb) || netif_elide_gro(dev)) { ++ res = netif_rx(skb); ++ goto unlock; ++ } + + cell = this_cpu_ptr(gcells->cells); + + if (skb_queue_len(&cell->napi_skbs) > netdev_max_backlog) { ++drop: + atomic_long_inc(&dev->rx_dropped); + kfree_skb(skb); +- return NET_RX_DROP; ++ res = NET_RX_DROP; ++ goto unlock; + } + + __skb_queue_tail(&cell->napi_skbs, skb); + if (skb_queue_len(&cell->napi_skbs) == 1) + napi_schedule(&cell->napi); +- return NET_RX_SUCCESS; ++ ++ res = NET_RX_SUCCESS; ++ ++unlock: ++ rcu_read_unlock(); ++ return res; + } + EXPORT_SYMBOL(gro_cells_receive); + diff --git a/queue-5.0/ipv4-route-fail-early-when-inet-dev-is-missing.patch b/queue-5.0/ipv4-route-fail-early-when-inet-dev-is-missing.patch new file mode 100644 index 00000000000..29bd77f5058 --- /dev/null +++ b/queue-5.0/ipv4-route-fail-early-when-inet-dev-is-missing.patch @@ -0,0 +1,50 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Paolo Abeni +Date: Wed, 6 Mar 2019 10:42:53 +0100 +Subject: ipv4/route: fail early when inet dev is missing + +From: Paolo Abeni + +[ Upstream commit 22c74764aa2943ecdf9f07c900d8a9c8ba6c9265 ] + +If a non local multicast packet reaches ip_route_input_rcu() while +the ingress device IPv4 private data (in_dev) is NULL, we end up +doing a NULL pointer dereference in IN_DEV_MFORWARD(). + +Since the later call to ip_route_input_mc() is going to fail if +!in_dev, we can fail early in such scenario and avoid the dangerous +code path. + +v1 -> v2: + - clarified the commit message, no code changes + +Reported-by: Tianhao Zhao +Fixes: e58e41596811 ("net: Enable support for VRF with ipv4 multicast") +Signed-off-by: Paolo Abeni +Reviewed-by: David Ahern +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/route.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/net/ipv4/route.c ++++ b/net/ipv4/route.c +@@ -2144,12 +2144,13 @@ int ip_route_input_rcu(struct sk_buff *s + int our = 0; + int err = -EINVAL; + +- if (in_dev) +- our = ip_check_mc_rcu(in_dev, daddr, saddr, +- ip_hdr(skb)->protocol); ++ if (!in_dev) ++ return err; ++ our = ip_check_mc_rcu(in_dev, daddr, saddr, ++ ip_hdr(skb)->protocol); + + /* check l3 master if no match yet */ +- if ((!in_dev || !our) && netif_is_l3_slave(dev)) { ++ if (!our && netif_is_l3_slave(dev)) { + struct in_device *l3_in_dev; + + l3_in_dev = __in_dev_get_rcu(skb->dev); diff --git a/queue-5.0/l2tp-fix-infoleak-in-l2tp_ip6_recvmsg.patch b/queue-5.0/l2tp-fix-infoleak-in-l2tp_ip6_recvmsg.patch new file mode 100644 index 00000000000..d672ae2003a --- /dev/null +++ b/queue-5.0/l2tp-fix-infoleak-in-l2tp_ip6_recvmsg.patch @@ -0,0 +1,83 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Eric Dumazet +Date: Tue, 12 Mar 2019 06:50:11 -0700 +Subject: l2tp: fix infoleak in l2tp_ip6_recvmsg() + +From: Eric Dumazet + +[ Upstream commit 163d1c3d6f17556ed3c340d3789ea93be95d6c28 ] + +Back in 2013 Hannes took care of most of such leaks in commit +bceaa90240b6 ("inet: prevent leakage of uninitialized memory to user in recv syscalls") + +But the bug in l2tp_ip6_recvmsg() has not been fixed. + +syzbot report : + +BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32 +CPU: 1 PID: 10996 Comm: syz-executor362 Not tainted 5.0.0+ #11 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 +Call Trace: + __dump_stack lib/dump_stack.c:77 [inline] + dump_stack+0x173/0x1d0 lib/dump_stack.c:113 + kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:600 + kmsan_internal_check_memory+0x9f4/0xb10 mm/kmsan/kmsan.c:694 + kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601 + _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32 + copy_to_user include/linux/uaccess.h:174 [inline] + move_addr_to_user+0x311/0x570 net/socket.c:227 + ___sys_recvmsg+0xb65/0x1310 net/socket.c:2283 + do_recvmmsg+0x646/0x10c0 net/socket.c:2390 + __sys_recvmmsg net/socket.c:2469 [inline] + __do_sys_recvmmsg net/socket.c:2492 [inline] + __se_sys_recvmmsg+0x1d1/0x350 net/socket.c:2485 + __x64_sys_recvmmsg+0x62/0x80 net/socket.c:2485 + do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 + entry_SYSCALL_64_after_hwframe+0x63/0xe7 +RIP: 0033:0x445819 +Code: e8 6c b6 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00 +RSP: 002b:00007f64453eddb8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b +RAX: ffffffffffffffda RBX: 00000000006dac28 RCX: 0000000000445819 +RDX: 0000000000000005 RSI: 0000000020002f80 RDI: 0000000000000003 +RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac2c +R13: 00007ffeba8f87af R14: 00007f64453ee9c0 R15: 20c49ba5e353f7cf + +Local variable description: ----addr@___sys_recvmsg +Variable was created at: + ___sys_recvmsg+0xf6/0x1310 net/socket.c:2244 + do_recvmmsg+0x646/0x10c0 net/socket.c:2390 + +Bytes 0-31 of 32 are uninitialized +Memory access of size 32 starts at ffff8880ae62fbb0 +Data copied to user address 0000000020000000 + +Fixes: a32e0eec7042 ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6") +Signed-off-by: Eric Dumazet +Reported-by: syzbot +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/l2tp/l2tp_ip6.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/net/l2tp/l2tp_ip6.c ++++ b/net/l2tp/l2tp_ip6.c +@@ -674,9 +674,6 @@ static int l2tp_ip6_recvmsg(struct sock + if (flags & MSG_OOB) + goto out; + +- if (addr_len) +- *addr_len = sizeof(*lsa); +- + if (flags & MSG_ERRQUEUE) + return ipv6_recv_error(sk, msg, len, addr_len); + +@@ -706,6 +703,7 @@ static int l2tp_ip6_recvmsg(struct sock + lsa->l2tp_conn_id = 0; + if (ipv6_addr_type(&lsa->l2tp_addr) & IPV6_ADDR_LINKLOCAL) + lsa->l2tp_scope_id = inet6_iif(skb); ++ *addr_len = sizeof(*lsa); + } + + if (np->rxopt.all) diff --git a/queue-5.0/lan743x-fix-rx-kernel-panic.patch b/queue-5.0/lan743x-fix-rx-kernel-panic.patch new file mode 100644 index 00000000000..50854a84a9a --- /dev/null +++ b/queue-5.0/lan743x-fix-rx-kernel-panic.patch @@ -0,0 +1,137 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Bryan Whitehead +Date: Mon, 11 Mar 2019 13:39:39 -0400 +Subject: lan743x: Fix RX Kernel Panic + +From: Bryan Whitehead + +[ Upstream commit dd9d9f5907bb475f8b1796c47d4ecc7fb9b72136 ] + +It has been noticed that running the speed test at +www.speedtest.net occasionally causes a kernel panic. + +Investigation revealed that under this test RX buffer allocation +sometimes fails and returns NULL. But the lan743x driver did +not handle this case. + +This patch fixes this issue by attempting to allocate a buffer +before sending the new rx packet to the OS. If the allocation +fails then the new rx packet is dropped and the existing buffer +is reused in the DMA ring. + +Updates for v2: + Additional 2 locations where allocation was not checked, + has been changed to reuse existing buffer. + +Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver") +Signed-off-by: Bryan Whitehead +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microchip/lan743x_main.c | 46 ++++++++++++++++++-------- + 1 file changed, 32 insertions(+), 14 deletions(-) + +--- a/drivers/net/ethernet/microchip/lan743x_main.c ++++ b/drivers/net/ethernet/microchip/lan743x_main.c +@@ -1902,7 +1902,17 @@ static int lan743x_rx_next_index(struct + return ((++index) % rx->ring_size); + } + +-static int lan743x_rx_allocate_ring_element(struct lan743x_rx *rx, int index) ++static struct sk_buff *lan743x_rx_allocate_skb(struct lan743x_rx *rx) ++{ ++ int length = 0; ++ ++ length = (LAN743X_MAX_FRAME_SIZE + ETH_HLEN + 4 + RX_HEAD_PADDING); ++ return __netdev_alloc_skb(rx->adapter->netdev, ++ length, GFP_ATOMIC | GFP_DMA); ++} ++ ++static int lan743x_rx_init_ring_element(struct lan743x_rx *rx, int index, ++ struct sk_buff *skb) + { + struct lan743x_rx_buffer_info *buffer_info; + struct lan743x_rx_descriptor *descriptor; +@@ -1911,9 +1921,7 @@ static int lan743x_rx_allocate_ring_elem + length = (LAN743X_MAX_FRAME_SIZE + ETH_HLEN + 4 + RX_HEAD_PADDING); + descriptor = &rx->ring_cpu_ptr[index]; + buffer_info = &rx->buffer_info[index]; +- buffer_info->skb = __netdev_alloc_skb(rx->adapter->netdev, +- length, +- GFP_ATOMIC | GFP_DMA); ++ buffer_info->skb = skb; + if (!(buffer_info->skb)) + return -ENOMEM; + buffer_info->dma_ptr = dma_map_single(&rx->adapter->pdev->dev, +@@ -2060,8 +2068,19 @@ static int lan743x_rx_process_packet(str + /* packet is available */ + if (first_index == last_index) { + /* single buffer packet */ ++ struct sk_buff *new_skb = NULL; + int packet_length; + ++ new_skb = lan743x_rx_allocate_skb(rx); ++ if (!new_skb) { ++ /* failed to allocate next skb. ++ * Memory is very low. ++ * Drop this packet and reuse buffer. ++ */ ++ lan743x_rx_reuse_ring_element(rx, first_index); ++ goto process_extension; ++ } ++ + buffer_info = &rx->buffer_info[first_index]; + skb = buffer_info->skb; + descriptor = &rx->ring_cpu_ptr[first_index]; +@@ -2081,7 +2100,7 @@ static int lan743x_rx_process_packet(str + skb_put(skb, packet_length - 4); + skb->protocol = eth_type_trans(skb, + rx->adapter->netdev); +- lan743x_rx_allocate_ring_element(rx, first_index); ++ lan743x_rx_init_ring_element(rx, first_index, new_skb); + } else { + int index = first_index; + +@@ -2094,26 +2113,23 @@ static int lan743x_rx_process_packet(str + if (first_index <= last_index) { + while ((index >= first_index) && + (index <= last_index)) { +- lan743x_rx_release_ring_element(rx, +- index); +- lan743x_rx_allocate_ring_element(rx, +- index); ++ lan743x_rx_reuse_ring_element(rx, ++ index); + index = lan743x_rx_next_index(rx, + index); + } + } else { + while ((index >= first_index) || + (index <= last_index)) { +- lan743x_rx_release_ring_element(rx, +- index); +- lan743x_rx_allocate_ring_element(rx, +- index); ++ lan743x_rx_reuse_ring_element(rx, ++ index); + index = lan743x_rx_next_index(rx, + index); + } + } + } + ++process_extension: + if (extension_index >= 0) { + descriptor = &rx->ring_cpu_ptr[extension_index]; + buffer_info = &rx->buffer_info[extension_index]; +@@ -2290,7 +2306,9 @@ static int lan743x_rx_ring_init(struct l + + rx->last_head = 0; + for (index = 0; index < rx->ring_size; index++) { +- ret = lan743x_rx_allocate_ring_element(rx, index); ++ struct sk_buff *new_skb = lan743x_rx_allocate_skb(rx); ++ ++ ret = lan743x_rx_init_ring_element(rx, index, new_skb); + if (ret) + goto cleanup; + } diff --git a/queue-5.0/lan743x-fix-tx-stall-issue.patch b/queue-5.0/lan743x-fix-tx-stall-issue.patch new file mode 100644 index 00000000000..2a1f57b48e8 --- /dev/null +++ b/queue-5.0/lan743x-fix-tx-stall-issue.patch @@ -0,0 +1,67 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Bryan Whitehead +Date: Wed, 13 Mar 2019 15:55:48 -0400 +Subject: lan743x: Fix TX Stall Issue + +From: Bryan Whitehead + +[ Upstream commit deb6bfabdbb634e91f36a4e9cb00a7137d72d886 ] + +It has been observed that tx queue may stall while downloading +from certain web sites (example www.speedtest.net) + +The cause has been tracked down to a corner case where +the tx interrupt vector was disabled automatically, but +was not re enabled later. + +The lan743x has two mechanisms to enable/disable individual +interrupts. Interrupts can be enabled/disabled by individual +source, and they can also be enabled/disabled by individual +vector which has been mapped to the source. Both must be +enabled for interrupts to work properly. + +The TX code path, primarily uses the interrupt enable/disable of +the TX source bit, while leaving the vector enabled all the time. + +However, while investigating this issue it was noticed that +the driver requested the use of the vector auto clear feature. + +The test above revealed a case where the vector enable was +cleared unintentionally. + +This patch fixes the issue by deleting the lines that request +the vector auto clear feature to be used. + +Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver") +Signed-off-by: Bryan Whitehead +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microchip/lan743x_main.c | 9 +-------- + 1 file changed, 1 insertion(+), 8 deletions(-) + +--- a/drivers/net/ethernet/microchip/lan743x_main.c ++++ b/drivers/net/ethernet/microchip/lan743x_main.c +@@ -585,8 +585,7 @@ static int lan743x_intr_open(struct lan7 + + if (adapter->csr.flags & + LAN743X_CSR_FLAG_SUPPORTS_INTR_AUTO_SET_CLR) { +- flags = LAN743X_VECTOR_FLAG_VECTOR_ENABLE_AUTO_CLEAR | +- LAN743X_VECTOR_FLAG_VECTOR_ENABLE_AUTO_SET | ++ flags = LAN743X_VECTOR_FLAG_VECTOR_ENABLE_AUTO_SET | + LAN743X_VECTOR_FLAG_SOURCE_ENABLE_AUTO_SET | + LAN743X_VECTOR_FLAG_SOURCE_ENABLE_AUTO_CLEAR | + LAN743X_VECTOR_FLAG_SOURCE_STATUS_AUTO_CLEAR; +@@ -599,12 +598,6 @@ static int lan743x_intr_open(struct lan7 + /* map TX interrupt to vector */ + int_vec_map1 |= INT_VEC_MAP1_TX_VEC_(index, vector); + lan743x_csr_write(adapter, INT_VEC_MAP1, int_vec_map1); +- if (flags & +- LAN743X_VECTOR_FLAG_VECTOR_ENABLE_AUTO_CLEAR) { +- int_vec_en_auto_clr |= INT_VEC_EN_(vector); +- lan743x_csr_write(adapter, INT_VEC_EN_AUTO_CLR, +- int_vec_en_auto_clr); +- } + + /* Remove TX interrupt from shared mask */ + intr->vector_list[0].int_mask &= ~int_bit; diff --git a/queue-5.0/net-dsa-mv88e6xxx-set-correct-interface-mode-for-cpu-dsa-ports.patch b/queue-5.0/net-dsa-mv88e6xxx-set-correct-interface-mode-for-cpu-dsa-ports.patch new file mode 100644 index 00000000000..7d9c1880262 --- /dev/null +++ b/queue-5.0/net-dsa-mv88e6xxx-set-correct-interface-mode-for-cpu-dsa-ports.patch @@ -0,0 +1,174 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Andrew Lunn +Date: Fri, 8 Mar 2019 01:21:27 +0100 +Subject: net: dsa: mv88e6xxx: Set correct interface mode for CPU/DSA ports + +From: Andrew Lunn + +[ Upstream commit 7cbbee050c959f41b512599bafd99685f419ce26 ] + +By default, the switch driver is expected to configure CPU and DSA +ports to their maximum speed. For the 6341 and 6390 families, the +ports interface mode has to be configured as well. The 6390X range +support 10G ports using XAUI, while the 6341 and 6390 supports +2500BaseX, as their maximum speed. + +Fixes: 787799a9d555 ("net: dsa: mv88e6xxx: Default ports 9/10 6390X CMODE to 1000BaseX") +Signed-off-by: Andrew Lunn +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/dsa/mv88e6xxx/chip.c | 11 +++++++++++ + drivers/net/dsa/mv88e6xxx/chip.h | 3 +++ + drivers/net/dsa/mv88e6xxx/port.c | 24 ++++++++++++++++++++++++ + drivers/net/dsa/mv88e6xxx/port.h | 4 ++++ + 4 files changed, 42 insertions(+) + +--- a/drivers/net/dsa/mv88e6xxx/chip.c ++++ b/drivers/net/dsa/mv88e6xxx/chip.c +@@ -559,6 +559,9 @@ static int mv88e6xxx_port_setup_mac(stru + goto restore_link; + } + ++ if (speed == SPEED_MAX && chip->info->ops->port_max_speed_mode) ++ mode = chip->info->ops->port_max_speed_mode(port); ++ + if (chip->info->ops->port_set_pause) { + err = chip->info->ops->port_set_pause(chip, port, pause); + if (err) +@@ -3042,6 +3045,7 @@ static const struct mv88e6xxx_ops mv88e6 + .port_set_duplex = mv88e6xxx_port_set_duplex, + .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay, + .port_set_speed = mv88e6341_port_set_speed, ++ .port_max_speed_mode = mv88e6341_port_max_speed_mode, + .port_tag_remap = mv88e6095_port_tag_remap, + .port_set_frame_mode = mv88e6351_port_set_frame_mode, + .port_set_egress_floods = mv88e6352_port_set_egress_floods, +@@ -3360,6 +3364,7 @@ static const struct mv88e6xxx_ops mv88e6 + .port_set_duplex = mv88e6xxx_port_set_duplex, + .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay, + .port_set_speed = mv88e6390_port_set_speed, ++ .port_max_speed_mode = mv88e6390_port_max_speed_mode, + .port_tag_remap = mv88e6390_port_tag_remap, + .port_set_frame_mode = mv88e6351_port_set_frame_mode, + .port_set_egress_floods = mv88e6352_port_set_egress_floods, +@@ -3404,6 +3409,7 @@ static const struct mv88e6xxx_ops mv88e6 + .port_set_duplex = mv88e6xxx_port_set_duplex, + .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay, + .port_set_speed = mv88e6390x_port_set_speed, ++ .port_max_speed_mode = mv88e6390x_port_max_speed_mode, + .port_tag_remap = mv88e6390_port_tag_remap, + .port_set_frame_mode = mv88e6351_port_set_frame_mode, + .port_set_egress_floods = mv88e6352_port_set_egress_floods, +@@ -3448,6 +3454,7 @@ static const struct mv88e6xxx_ops mv88e6 + .port_set_duplex = mv88e6xxx_port_set_duplex, + .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay, + .port_set_speed = mv88e6390_port_set_speed, ++ .port_max_speed_mode = mv88e6390_port_max_speed_mode, + .port_tag_remap = mv88e6390_port_tag_remap, + .port_set_frame_mode = mv88e6351_port_set_frame_mode, + .port_set_egress_floods = mv88e6352_port_set_egress_floods, +@@ -3541,6 +3548,7 @@ static const struct mv88e6xxx_ops mv88e6 + .port_set_duplex = mv88e6xxx_port_set_duplex, + .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay, + .port_set_speed = mv88e6390_port_set_speed, ++ .port_max_speed_mode = mv88e6390_port_max_speed_mode, + .port_tag_remap = mv88e6390_port_tag_remap, + .port_set_frame_mode = mv88e6351_port_set_frame_mode, + .port_set_egress_floods = mv88e6352_port_set_egress_floods, +@@ -3672,6 +3680,7 @@ static const struct mv88e6xxx_ops mv88e6 + .port_set_duplex = mv88e6xxx_port_set_duplex, + .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay, + .port_set_speed = mv88e6341_port_set_speed, ++ .port_max_speed_mode = mv88e6341_port_max_speed_mode, + .port_tag_remap = mv88e6095_port_tag_remap, + .port_set_frame_mode = mv88e6351_port_set_frame_mode, + .port_set_egress_floods = mv88e6352_port_set_egress_floods, +@@ -3847,6 +3856,7 @@ static const struct mv88e6xxx_ops mv88e6 + .port_set_duplex = mv88e6xxx_port_set_duplex, + .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay, + .port_set_speed = mv88e6390_port_set_speed, ++ .port_max_speed_mode = mv88e6390_port_max_speed_mode, + .port_tag_remap = mv88e6390_port_tag_remap, + .port_set_frame_mode = mv88e6351_port_set_frame_mode, + .port_set_egress_floods = mv88e6352_port_set_egress_floods, +@@ -3895,6 +3905,7 @@ static const struct mv88e6xxx_ops mv88e6 + .port_set_duplex = mv88e6xxx_port_set_duplex, + .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay, + .port_set_speed = mv88e6390x_port_set_speed, ++ .port_max_speed_mode = mv88e6390x_port_max_speed_mode, + .port_tag_remap = mv88e6390_port_tag_remap, + .port_set_frame_mode = mv88e6351_port_set_frame_mode, + .port_set_egress_floods = mv88e6352_port_set_egress_floods, +--- a/drivers/net/dsa/mv88e6xxx/chip.h ++++ b/drivers/net/dsa/mv88e6xxx/chip.h +@@ -377,6 +377,9 @@ struct mv88e6xxx_ops { + */ + int (*port_set_speed)(struct mv88e6xxx_chip *chip, int port, int speed); + ++ /* What interface mode should be used for maximum speed? */ ++ phy_interface_t (*port_max_speed_mode)(int port); ++ + int (*port_tag_remap)(struct mv88e6xxx_chip *chip, int port); + + int (*port_set_frame_mode)(struct mv88e6xxx_chip *chip, int port, +--- a/drivers/net/dsa/mv88e6xxx/port.c ++++ b/drivers/net/dsa/mv88e6xxx/port.c +@@ -312,6 +312,14 @@ int mv88e6341_port_set_speed(struct mv88 + return mv88e6xxx_port_set_speed(chip, port, speed, !port, true); + } + ++phy_interface_t mv88e6341_port_max_speed_mode(int port) ++{ ++ if (port == 5) ++ return PHY_INTERFACE_MODE_2500BASEX; ++ ++ return PHY_INTERFACE_MODE_NA; ++} ++ + /* Support 10, 100, 200, 1000 Mbps (e.g. 88E6352 family) */ + int mv88e6352_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed) + { +@@ -345,6 +353,14 @@ int mv88e6390_port_set_speed(struct mv88 + return mv88e6xxx_port_set_speed(chip, port, speed, true, true); + } + ++phy_interface_t mv88e6390_port_max_speed_mode(int port) ++{ ++ if (port == 9 || port == 10) ++ return PHY_INTERFACE_MODE_2500BASEX; ++ ++ return PHY_INTERFACE_MODE_NA; ++} ++ + /* Support 10, 100, 200, 1000, 2500, 10000 Mbps (e.g. 88E6190X) */ + int mv88e6390x_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed) + { +@@ -360,6 +376,14 @@ int mv88e6390x_port_set_speed(struct mv8 + return mv88e6xxx_port_set_speed(chip, port, speed, true, true); + } + ++phy_interface_t mv88e6390x_port_max_speed_mode(int port) ++{ ++ if (port == 9 || port == 10) ++ return PHY_INTERFACE_MODE_XAUI; ++ ++ return PHY_INTERFACE_MODE_NA; ++} ++ + int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip, int port, + phy_interface_t mode) + { +--- a/drivers/net/dsa/mv88e6xxx/port.h ++++ b/drivers/net/dsa/mv88e6xxx/port.h +@@ -285,6 +285,10 @@ int mv88e6352_port_set_speed(struct mv88 + int mv88e6390_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed); + int mv88e6390x_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed); + ++phy_interface_t mv88e6341_port_max_speed_mode(int port); ++phy_interface_t mv88e6390_port_max_speed_mode(int port); ++phy_interface_t mv88e6390x_port_max_speed_mode(int port); ++ + int mv88e6xxx_port_set_state(struct mv88e6xxx_chip *chip, int port, u8 state); + + int mv88e6xxx_port_set_vlan_map(struct mv88e6xxx_chip *chip, int port, u16 map); diff --git a/queue-5.0/net-hns3-add-dma_rmb-for-rx-description.patch b/queue-5.0/net-hns3-add-dma_rmb-for-rx-description.patch new file mode 100644 index 00000000000..787cee4bef2 --- /dev/null +++ b/queue-5.0/net-hns3-add-dma_rmb-for-rx-description.patch @@ -0,0 +1,33 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Jian Shen +Date: Wed, 6 Mar 2019 11:26:37 +0800 +Subject: net: hns3: add dma_rmb() for rx description + +From: Jian Shen + +[ Upstream commit d394d33bee22421b39a0bcdc51ca6d68ba308625 ] + +HW can not guarantee complete write desc->rx.size, even though +HNS3_RXD_VLD_B has been set. Driver needs to add dma_rmb() +instruction to make sure desc->rx.size is always valid. + +Fixes: e55970950556 ("net: hns3: Add handling of GRO Pkts not fully RX'ed in NAPI poll") +Signed-off-by: Jian Shen +Signed-off-by: Huazhong Tan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c ++++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +@@ -2476,6 +2476,8 @@ static int hns3_add_frag(struct hns3_ene + desc = &ring->desc[ring->next_to_clean]; + desc_cb = &ring->desc_cb[ring->next_to_clean]; + bd_base_info = le32_to_cpu(desc->rx.bd_base_info); ++ /* make sure HW write desc complete */ ++ dma_rmb(); + if (!hnae3_get_bit(bd_base_info, HNS3_RXD_VLD_B)) + return -ENXIO; + diff --git a/queue-5.0/net-hns3-fix-to-stop-multiple-hns-reset-due-to-the-aer-changes.patch b/queue-5.0/net-hns3-fix-to-stop-multiple-hns-reset-due-to-the-aer-changes.patch new file mode 100644 index 00000000000..9722b7336ea --- /dev/null +++ b/queue-5.0/net-hns3-fix-to-stop-multiple-hns-reset-due-to-the-aer-changes.patch @@ -0,0 +1,86 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Shiju Jose +Date: Sun, 10 Mar 2019 14:47:51 +0800 +Subject: net: hns3: fix to stop multiple HNS reset due to the AER changes + +From: Shiju Jose + +[ Upstream commit 69b51bbb03f73e04c486f79d1556b2d9becf4dbc ] + +The commit bfcb79fca19d +("PCI/ERR: Run error recovery callbacks for all affected devices") +affected the non-fatal error recovery logic for the HNS and RDMA devices. +This is because each HNS PF under PCIe bus receive callbacks +from the AER driver when an error is reported for one of the PF. +This causes unwanted PF resets because +the HNS decides which PF to reset based on the reset type set. +The HNS error handling code sets the reset type based on the hw error +type detected. + +This patch provides fix for the above issue for the recovery of +the hw errors in the HNS and RDMA devices. + +This patch needs backporting to the kernel v5.0+ + +Fixes: 332fbf576579 ("net: hns3: add handling of hw ras errors using new set of commands") +Reported-by: Xiaofei Tan +Signed-off-by: Shiju Jose +Signed-off-by: Huazhong Tan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 + + drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 +++- + drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 9 +++++++-- + 3 files changed, 11 insertions(+), 3 deletions(-) + +--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h ++++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h +@@ -192,6 +192,7 @@ struct hnae3_ae_dev { + const struct hnae3_ae_ops *ops; + struct list_head node; + u32 flag; ++ u8 override_pci_need_reset; /* fix to stop multiple reset happening */ + enum hnae3_dev_type dev_type; + enum hnae3_reset_type reset_type; + void *priv; +--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c ++++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +@@ -1852,7 +1852,9 @@ static pci_ers_result_t hns3_slot_reset( + + /* request the reset */ + if (ae_dev->ops->reset_event) { +- ae_dev->ops->reset_event(pdev, NULL); ++ if (!ae_dev->override_pci_need_reset) ++ ae_dev->ops->reset_event(pdev, NULL); ++ + return PCI_ERS_RESULT_RECOVERED; + } + +--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c ++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c +@@ -1259,8 +1259,10 @@ pci_ers_result_t hclge_handle_hw_ras_err + hclge_handle_all_ras_errors(hdev); + } else { + if (test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state) || +- hdev->pdev->revision < 0x21) ++ hdev->pdev->revision < 0x21) { ++ ae_dev->override_pci_need_reset = 1; + return PCI_ERS_RESULT_RECOVERED; ++ } + } + + if (status & HCLGE_RAS_REG_ROCEE_ERR_MASK) { +@@ -1269,8 +1271,11 @@ pci_ers_result_t hclge_handle_hw_ras_err + } + + if (status & HCLGE_RAS_REG_NFE_MASK || +- status & HCLGE_RAS_REG_ROCEE_ERR_MASK) ++ status & HCLGE_RAS_REG_ROCEE_ERR_MASK) { ++ ae_dev->override_pci_need_reset = 0; + return PCI_ERS_RESULT_NEED_RESET; ++ } ++ ae_dev->override_pci_need_reset = 1; + + return PCI_ERS_RESULT_RECOVERED; + } diff --git a/queue-5.0/net-hsr-fix-memory-leak-in-hsr_dev_finalize.patch b/queue-5.0/net-hsr-fix-memory-leak-in-hsr_dev_finalize.patch new file mode 100644 index 00000000000..fbd23ad6502 --- /dev/null +++ b/queue-5.0/net-hsr-fix-memory-leak-in-hsr_dev_finalize.patch @@ -0,0 +1,102 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Mao Wenan +Date: Wed, 6 Mar 2019 22:45:01 +0800 +Subject: net: hsr: fix memory leak in hsr_dev_finalize() + +From: Mao Wenan + +[ Upstream commit 3dc6da493a29dbeda9f13b637bd9c02c414b2261 ] + +If hsr_add_port(hsr, hsr_dev, HSR_PT_MASTER) failed to +add port, it directly returns res and forgets to free the node +that allocated in hsr_create_self_node(), and forgets to delete +the node->mac_list linked in hsr->self_node_db. + +BUG: memory leak +unreferenced object 0xffff8881cfa0c780 (size 64): + comm "syz-executor.0", pid 2077, jiffies 4294717969 (age 2415.377s) + hex dump (first 32 bytes): + e0 c7 a0 cf 81 88 ff ff 00 02 00 00 00 00 ad de ................ + 00 e6 49 cd 81 88 ff ff c0 9b 87 d0 81 88 ff ff ..I............. + backtrace: + [<00000000e2ff5070>] hsr_dev_finalize+0x736/0x960 [hsr] + [<000000003ed2e597>] hsr_newlink+0x2b2/0x3e0 [hsr] + [<000000003fa8c6b6>] __rtnl_newlink+0xf1f/0x1600 net/core/rtnetlink.c:3182 + [<000000001247a7ad>] rtnl_newlink+0x66/0x90 net/core/rtnetlink.c:3240 + [<00000000e7d1b61d>] rtnetlink_rcv_msg+0x54e/0xb90 net/core/rtnetlink.c:5130 + [<000000005556bd3a>] netlink_rcv_skb+0x129/0x340 net/netlink/af_netlink.c:2477 + [<00000000741d5ee6>] netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] + [<00000000741d5ee6>] netlink_unicast+0x49a/0x650 net/netlink/af_netlink.c:1336 + [<000000009d56f9b7>] netlink_sendmsg+0x88b/0xdf0 net/netlink/af_netlink.c:1917 + [<0000000046b35c59>] sock_sendmsg_nosec net/socket.c:621 [inline] + [<0000000046b35c59>] sock_sendmsg+0xc3/0x100 net/socket.c:631 + [<00000000d208adc9>] __sys_sendto+0x33e/0x560 net/socket.c:1786 + [<00000000b582837a>] __do_sys_sendto net/socket.c:1798 [inline] + [<00000000b582837a>] __se_sys_sendto net/socket.c:1794 [inline] + [<00000000b582837a>] __x64_sys_sendto+0xdd/0x1b0 net/socket.c:1794 + [<00000000c866801d>] do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 + [<00000000fea382d9>] entry_SYSCALL_64_after_hwframe+0x49/0xbe + [<00000000e01dacb3>] 0xffffffffffffffff + +Fixes: c5a759117210 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.") +Reported-by: Hulk Robot +Signed-off-by: Mao Wenan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/hsr/hsr_device.c | 4 +++- + net/hsr/hsr_framereg.c | 12 ++++++++++++ + net/hsr/hsr_framereg.h | 1 + + 3 files changed, 16 insertions(+), 1 deletion(-) + +--- a/net/hsr/hsr_device.c ++++ b/net/hsr/hsr_device.c +@@ -486,7 +486,7 @@ int hsr_dev_finalize(struct net_device * + + res = hsr_add_port(hsr, hsr_dev, HSR_PT_MASTER); + if (res) +- return res; ++ goto err_add_port; + + res = register_netdevice(hsr_dev); + if (res) +@@ -506,6 +506,8 @@ int hsr_dev_finalize(struct net_device * + fail: + hsr_for_each_port(hsr, port) + hsr_del_port(port); ++err_add_port: ++ hsr_del_node(&hsr->self_node_db); + + return res; + } +--- a/net/hsr/hsr_framereg.c ++++ b/net/hsr/hsr_framereg.c +@@ -124,6 +124,18 @@ int hsr_create_self_node(struct list_hea + return 0; + } + ++void hsr_del_node(struct list_head *self_node_db) ++{ ++ struct hsr_node *node; ++ ++ rcu_read_lock(); ++ node = list_first_or_null_rcu(self_node_db, struct hsr_node, mac_list); ++ rcu_read_unlock(); ++ if (node) { ++ list_del_rcu(&node->mac_list); ++ kfree(node); ++ } ++} + + /* Allocate an hsr_node and add it to node_db. 'addr' is the node's AddressA; + * seq_out is used to initialize filtering of outgoing duplicate frames +--- a/net/hsr/hsr_framereg.h ++++ b/net/hsr/hsr_framereg.h +@@ -16,6 +16,7 @@ + + struct hsr_node; + ++void hsr_del_node(struct list_head *self_node_db); + struct hsr_node *hsr_add_node(struct list_head *node_db, unsigned char addr[], + u16 seq_out); + struct hsr_node *hsr_get_node(struct hsr_port *port, struct sk_buff *skb, diff --git a/queue-5.0/net-hsr-fix-possible-crash-in-add_timer.patch b/queue-5.0/net-hsr-fix-possible-crash-in-add_timer.patch new file mode 100644 index 00000000000..4f55c6424dc --- /dev/null +++ b/queue-5.0/net-hsr-fix-possible-crash-in-add_timer.patch @@ -0,0 +1,135 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Eric Dumazet +Date: Thu, 7 Mar 2019 09:36:33 -0800 +Subject: net/hsr: fix possible crash in add_timer() + +From: Eric Dumazet + +[ Upstream commit 1e027960edfaa6a43f9ca31081729b716598112b ] + +syzbot found another add_timer() issue, this time in net/hsr [1] + +Let's use mod_timer() which is safe. + +[1] +kernel BUG at kernel/time/timer.c:1136! +invalid opcode: 0000 [#1] PREEMPT SMP KASAN +CPU: 0 PID: 15909 Comm: syz-executor.3 Not tainted 5.0.0+ #97 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 +kobject: 'loop2' (00000000f5629718): kobject_uevent_env +RIP: 0010:add_timer kernel/time/timer.c:1136 [inline] +RIP: 0010:add_timer+0x654/0xbe0 kernel/time/timer.c:1134 +Code: 0f 94 c5 31 ff 44 89 ee e8 09 61 0f 00 45 84 ed 0f 84 77 fd ff ff e8 bb 5f 0f 00 e8 07 10 a0 ff e9 68 fd ff ff e8 ac 5f 0f 00 <0f> 0b e8 a5 5f 0f 00 0f 0b e8 9e 5f 0f 00 4c 89 b5 58 ff ff ff e9 +RSP: 0018:ffff8880656eeca0 EFLAGS: 00010246 +kobject: 'loop2' (00000000f5629718): fill_kobj_path: path = '/devices/virtual/block/loop2' +RAX: 0000000000040000 RBX: 1ffff1100caddd9a RCX: ffffc9000c436000 +RDX: 0000000000040000 RSI: ffffffff816056c4 RDI: ffff88806a2f6cc8 +RBP: ffff8880656eed58 R08: ffff888067f4a300 R09: ffff888067f4abc8 +R10: 0000000000000000 R11: 0000000000000000 R12: ffff88806a2f6cc0 +R13: dffffc0000000000 R14: 0000000000000001 R15: ffff8880656eed30 +FS: 00007fc2019bf700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 0000000000738000 CR3: 0000000067e8e000 CR4: 00000000001406f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + hsr_check_announce net/hsr/hsr_device.c:99 [inline] + hsr_check_carrier_and_operstate+0x567/0x6f0 net/hsr/hsr_device.c:120 + hsr_netdev_notify+0x297/0xa00 net/hsr/hsr_main.c:51 + notifier_call_chain+0xc7/0x240 kernel/notifier.c:93 + __raw_notifier_call_chain kernel/notifier.c:394 [inline] + raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401 + call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739 + call_netdevice_notifiers_extack net/core/dev.c:1751 [inline] + call_netdevice_notifiers net/core/dev.c:1765 [inline] + dev_open net/core/dev.c:1436 [inline] + dev_open+0x143/0x160 net/core/dev.c:1424 + team_port_add drivers/net/team/team.c:1203 [inline] + team_add_slave+0xa07/0x15d0 drivers/net/team/team.c:1933 + do_set_master net/core/rtnetlink.c:2358 [inline] + do_set_master+0x1d4/0x230 net/core/rtnetlink.c:2332 + do_setlink+0x966/0x3510 net/core/rtnetlink.c:2493 + rtnl_setlink+0x271/0x3b0 net/core/rtnetlink.c:2747 + rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192 + netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485 + rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210 + netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] + netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336 + netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925 + sock_sendmsg_nosec net/socket.c:622 [inline] + sock_sendmsg+0xdd/0x130 net/socket.c:632 + sock_write_iter+0x27c/0x3e0 net/socket.c:923 + call_write_iter include/linux/fs.h:1869 [inline] + do_iter_readv_writev+0x5e0/0x8e0 fs/read_write.c:680 + do_iter_write fs/read_write.c:956 [inline] + do_iter_write+0x184/0x610 fs/read_write.c:937 + vfs_writev+0x1b3/0x2f0 fs/read_write.c:1001 + do_writev+0xf6/0x290 fs/read_write.c:1036 + __do_sys_writev fs/read_write.c:1109 [inline] + __se_sys_writev fs/read_write.c:1106 [inline] + __x64_sys_writev+0x75/0xb0 fs/read_write.c:1106 + do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 + entry_SYSCALL_64_after_hwframe+0x49/0xbe +RIP: 0033:0x457f29 +Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 +RSP: 002b:00007fc2019bec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 +RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457f29 +RDX: 0000000000000001 RSI: 00000000200000c0 RDI: 0000000000000003 +RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc2019bf6d4 +R13: 00000000004c4a60 R14: 00000000004dd218 R15: 00000000ffffffff + +Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") +Signed-off-by: Eric Dumazet +Reported-by: syzbot +Cc: Arvid Brodin +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/hsr/hsr_device.c | 14 ++++++-------- + 1 file changed, 6 insertions(+), 8 deletions(-) + +--- a/net/hsr/hsr_device.c ++++ b/net/hsr/hsr_device.c +@@ -94,9 +94,8 @@ static void hsr_check_announce(struct ne + && (old_operstate != IF_OPER_UP)) { + /* Went up */ + hsr->announce_count = 0; +- hsr->announce_timer.expires = jiffies + +- msecs_to_jiffies(HSR_ANNOUNCE_INTERVAL); +- add_timer(&hsr->announce_timer); ++ mod_timer(&hsr->announce_timer, ++ jiffies + msecs_to_jiffies(HSR_ANNOUNCE_INTERVAL)); + } + + if ((hsr_dev->operstate != IF_OPER_UP) && (old_operstate == IF_OPER_UP)) +@@ -332,6 +331,7 @@ static void hsr_announce(struct timer_li + { + struct hsr_priv *hsr; + struct hsr_port *master; ++ unsigned long interval; + + hsr = from_timer(hsr, t, announce_timer); + +@@ -343,18 +343,16 @@ static void hsr_announce(struct timer_li + hsr->protVersion); + hsr->announce_count++; + +- hsr->announce_timer.expires = jiffies + +- msecs_to_jiffies(HSR_ANNOUNCE_INTERVAL); ++ interval = msecs_to_jiffies(HSR_ANNOUNCE_INTERVAL); + } else { + send_hsr_supervision_frame(master, HSR_TLV_LIFE_CHECK, + hsr->protVersion); + +- hsr->announce_timer.expires = jiffies + +- msecs_to_jiffies(HSR_LIFE_CHECK_INTERVAL); ++ interval = msecs_to_jiffies(HSR_LIFE_CHECK_INTERVAL); + } + + if (is_admin_up(master->dev)) +- add_timer(&hsr->announce_timer); ++ mod_timer(&hsr->announce_timer, jiffies + interval); + + rcu_read_unlock(); + } diff --git a/queue-5.0/net-mlx4_core-fix-locking-in-sriov-mode-when-switching-between-events-and-polling.patch b/queue-5.0/net-mlx4_core-fix-locking-in-sriov-mode-when-switching-between-events-and-polling.patch new file mode 100644 index 00000000000..f217bf94652 --- /dev/null +++ b/queue-5.0/net-mlx4_core-fix-locking-in-sriov-mode-when-switching-between-events-and-polling.patch @@ -0,0 +1,72 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Jack Morgenstein +Date: Tue, 12 Mar 2019 17:05:48 +0200 +Subject: net/mlx4_core: Fix locking in SRIOV mode when switching between events and polling + +From: Jack Morgenstein + +[ Upstream commit c07d27927f2f2e96fcd27bb9fb330c9ea65612d0 ] + +In procedures mlx4_cmd_use_events() and mlx4_cmd_use_polling(), we need to +guarantee that there are no FW commands in progress on the comm channel +(for VFs) or wrapped FW commands (on the PF) when SRIOV is active. + +We do this by also taking the slave_cmd_mutex when SRIOV is active. + +This is especially important when switching from event to polling, since we +free the command-context array during the switch. If there are FW commands +in progress (e.g., waiting for a completion event), the completion event +handler will access freed memory. + +Since the decision to use comm_wait or comm_poll is taken before grabbing +the event_sem/poll_sem in mlx4_comm_cmd_wait/poll, we must take the +slave_cmd_mutex as well (to guarantee that the decision to use events or +polling and the call to the appropriate cmd function are atomic). + +Fixes: a7e1f04905e5 ("net/mlx4_core: Fix deadlock when switching between polling and event fw commands") +Signed-off-by: Jack Morgenstein +Signed-off-by: Tariq Toukan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/mellanox/mlx4/cmd.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c ++++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c +@@ -2645,6 +2645,8 @@ int mlx4_cmd_use_events(struct mlx4_dev + if (!priv->cmd.context) + return -ENOMEM; + ++ if (mlx4_is_mfunc(dev)) ++ mutex_lock(&priv->cmd.slave_cmd_mutex); + down_write(&priv->cmd.switch_sem); + for (i = 0; i < priv->cmd.max_cmds; ++i) { + priv->cmd.context[i].token = i; +@@ -2670,6 +2672,8 @@ int mlx4_cmd_use_events(struct mlx4_dev + down(&priv->cmd.poll_sem); + priv->cmd.use_events = 1; + up_write(&priv->cmd.switch_sem); ++ if (mlx4_is_mfunc(dev)) ++ mutex_unlock(&priv->cmd.slave_cmd_mutex); + + return err; + } +@@ -2682,6 +2686,8 @@ void mlx4_cmd_use_polling(struct mlx4_de + struct mlx4_priv *priv = mlx4_priv(dev); + int i; + ++ if (mlx4_is_mfunc(dev)) ++ mutex_lock(&priv->cmd.slave_cmd_mutex); + down_write(&priv->cmd.switch_sem); + priv->cmd.use_events = 0; + +@@ -2693,6 +2699,8 @@ void mlx4_cmd_use_polling(struct mlx4_de + + up(&priv->cmd.poll_sem); + up_write(&priv->cmd.switch_sem); ++ if (mlx4_is_mfunc(dev)) ++ mutex_unlock(&priv->cmd.slave_cmd_mutex); + } + + struct mlx4_cmd_mailbox *mlx4_alloc_cmd_mailbox(struct mlx4_dev *dev) diff --git a/queue-5.0/net-mlx4_core-fix-qp-mtt-size-calculation.patch b/queue-5.0/net-mlx4_core-fix-qp-mtt-size-calculation.patch new file mode 100644 index 00000000000..1acafc8ac68 --- /dev/null +++ b/queue-5.0/net-mlx4_core-fix-qp-mtt-size-calculation.patch @@ -0,0 +1,68 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Jack Morgenstein +Date: Tue, 12 Mar 2019 17:05:49 +0200 +Subject: net/mlx4_core: Fix qp mtt size calculation + +From: Jack Morgenstein + +[ Upstream commit 8511a653e9250ef36b95803c375a7be0e2edb628 ] + +Calculation of qp mtt size (in function mlx4_RST2INIT_wrapper) +ultimately depends on function roundup_pow_of_two. + +If the amount of memory required by the QP is less than one page, +roundup_pow_of_two is called with argument zero. In this case, the +roundup_pow_of_two result is undefined. + +Calling roundup_pow_of_two with a zero argument resulted in the +following stack trace: + +UBSAN: Undefined behaviour in ./include/linux/log2.h:61:13 +shift exponent 64 is too large for 64-bit type 'long unsigned int' +CPU: 4 PID: 26939 Comm: rping Tainted: G OE 4.19.0-rc1 +Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 3.2a 07/09/2015 +Call Trace: +dump_stack+0x9a/0xeb +ubsan_epilogue+0x9/0x7c +__ubsan_handle_shift_out_of_bounds+0x254/0x29d +? __ubsan_handle_load_invalid_value+0x180/0x180 +? debug_show_all_locks+0x310/0x310 +? sched_clock+0x5/0x10 +? sched_clock+0x5/0x10 +? sched_clock_cpu+0x18/0x260 +? find_held_lock+0x35/0x1e0 +? mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core] +mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core] + +Fix this by explicitly testing for zero, and returning one if the +argument is zero (assuming that the next higher power of 2 in this case +should be one). + +Fixes: c82e9aa0a8bc ("mlx4_core: resource tracking for HCA resources used by guests") +Signed-off-by: Jack Morgenstein +Signed-off-by: Tariq Toukan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c ++++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c +@@ -2719,13 +2719,13 @@ static int qp_get_mtt_size(struct mlx4_q + int total_pages; + int total_mem; + int page_offset = (be32_to_cpu(qpc->params2) >> 6) & 0x3f; ++ int tot; + + sq_size = 1 << (log_sq_size + log_sq_sride + 4); + rq_size = (srq|rss|xrc) ? 0 : (1 << (log_rq_size + log_rq_stride + 4)); + total_mem = sq_size + rq_size; +- total_pages = +- roundup_pow_of_two((total_mem + (page_offset << 6)) >> +- page_shift); ++ tot = (total_mem + (page_offset << 6)) >> page_shift; ++ total_pages = !tot ? 1 : roundup_pow_of_two(tot); + + return total_pages; + } diff --git a/queue-5.0/net-mlx4_core-fix-reset-flow-when-in-command-polling-mode.patch b/queue-5.0/net-mlx4_core-fix-reset-flow-when-in-command-polling-mode.patch new file mode 100644 index 00000000000..de5d62157c7 --- /dev/null +++ b/queue-5.0/net-mlx4_core-fix-reset-flow-when-in-command-polling-mode.patch @@ -0,0 +1,85 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Jack Morgenstein +Date: Tue, 12 Mar 2019 17:05:47 +0200 +Subject: net/mlx4_core: Fix reset flow when in command polling mode + +From: Jack Morgenstein + +[ Upstream commit e15ce4b8d11227007577e6dc1364d288b8874fbe ] + +As part of unloading a device, the driver switches from +FW command event mode to FW command polling mode. + +Part of switching over to polling mode is freeing the command context array +memory (unfortunately, currently, without NULLing the command context array +pointer). + +The reset flow calls "complete" to complete all outstanding fw commands +(if we are in event mode). The check for event vs. polling mode here +is to test if the command context array pointer is NULL. + +If the reset flow is activated after the switch to polling mode, it will +attempt (incorrectly) to complete all the commands in the context array -- +because the pointer was not NULLed when the driver switched over to polling +mode. + +As a result, we have a use-after-free situation, which results in a +kernel crash. + +For example: +BUG: unable to handle kernel NULL pointer dereference at (null) +IP: [] __wake_up_common+0x2e/0x90 +PGD 0 +Oops: 0000 [#1] SMP +Modules linked in: netconsole nfsv3 nfs_acl nfs lockd grace ... +CPU: 2 PID: 940 Comm: kworker/2:3 Kdump: loaded Not tainted 3.10.0-862.el7.x86_64 #1 +Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 04/28/2016 +Workqueue: events hv_eject_device_work [pci_hyperv] +task: ffff8d1734ca0fd0 ti: ffff8d17354bc000 task.ti: ffff8d17354bc000 +RIP: 0010:[] [] __wake_up_common+0x2e/0x90 +RSP: 0018:ffff8d17354bfa38 EFLAGS: 00010082 +RAX: 0000000000000000 RBX: ffff8d17362d42c8 RCX: 0000000000000000 +RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8d17362d42c8 +RBP: ffff8d17354bfa70 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000298 R11: ffff8d173610e000 R12: ffff8d17362d42d0 +R13: 0000000000000246 R14: 0000000000000000 R15: 0000000000000003 +FS: 0000000000000000(0000) GS:ffff8d1802680000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 0000000000000000 CR3: 00000000f16d8000 CR4: 00000000001406e0 +Call Trace: + [] complete+0x3c/0x50 + [] mlx4_cmd_wake_completions+0x70/0x90 [mlx4_core] + [] mlx4_enter_error_state+0xe1/0x380 [mlx4_core] + [] mlx4_comm_cmd+0x29b/0x360 [mlx4_core] + [] __mlx4_cmd+0x441/0x920 [mlx4_core] + [] ? __slab_free+0x81/0x2f0 + [] ? __radix_tree_lookup+0x84/0xf0 + [] mlx4_free_mtt_range+0x5b/0xb0 [mlx4_core] + [] mlx4_mtt_cleanup+0x17/0x20 [mlx4_core] + [] mlx4_free_eq+0xa7/0x1c0 [mlx4_core] + [] mlx4_cleanup_eq_table+0xde/0x130 [mlx4_core] + [] mlx4_unload_one+0x118/0x300 [mlx4_core] + [] mlx4_remove_one+0x91/0x1f0 [mlx4_core] + +The fix is to set the command context array pointer to NULL after freeing +the array. + +Fixes: f5aef5aa3506 ("net/mlx4_core: Activate reset flow upon fatal command cases") +Signed-off-by: Jack Morgenstein +Signed-off-by: Tariq Toukan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/mellanox/mlx4/cmd.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c ++++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c +@@ -2689,6 +2689,7 @@ void mlx4_cmd_use_polling(struct mlx4_de + down(&priv->cmd.event_sem); + + kfree(priv->cmd.context); ++ priv->cmd.context = NULL; + + up(&priv->cmd.poll_sem); + up_write(&priv->cmd.switch_sem); diff --git a/queue-5.0/net-sched-flower-insert-new-filter-to-idr-after-setting-its-mask.patch b/queue-5.0/net-sched-flower-insert-new-filter-to-idr-after-setting-its-mask.patch new file mode 100644 index 00000000000..cc05ee25e40 --- /dev/null +++ b/queue-5.0/net-sched-flower-insert-new-filter-to-idr-after-setting-its-mask.patch @@ -0,0 +1,141 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Vlad Buslov +Date: Wed, 6 Mar 2019 16:22:12 +0200 +Subject: net: sched: flower: insert new filter to idr after setting its mask + +From: Vlad Buslov + +[ Upstream commit ecb3dea400d3beaf611ce76ac7a51d4230492cf2 ] + +When adding new filter to flower classifier, fl_change() inserts it to +handle_idr before initializing filter extensions and assigning it a mask. +Normally this ordering doesn't matter because all flower classifier ops +callbacks assume rtnl lock protection. However, when filter has an action +that doesn't have its kernel module loaded, rtnl lock is released before +call to request_module(). During this time the filter can be accessed bu +concurrent task before its initialization is completed, which can lead to a +crash. + +Example case of NULL pointer dereference in concurrent dump: + +Task 1 Task 2 + +tc_new_tfilter() + fl_change() + idr_alloc_u32(fnew) + fl_set_parms() + tcf_exts_validate() + tcf_action_init() + tcf_action_init_1() + rtnl_unlock() + request_module() + ... rtnl_lock() + tc_dump_tfilter() + tcf_chain_dump() + fl_walk() + idr_get_next_ul() + tcf_node_dump() + tcf_fill_node() + fl_dump() + mask = &f->mask->key; <- NULL ptr + rtnl_lock() + +Extension initialization and mask assignment don't depend on fnew->handle +that is allocated by idr_alloc_u32(). Move idr allocation code after action +creation and mask assignment in fl_change() to prevent concurrent access +to not fully initialized filter when rtnl lock is released to load action +module. + +Fixes: 01683a146999 ("net: sched: refactor flower walk to iterate over idr") +Signed-off-by: Vlad Buslov +Reviewed-by: Roi Dayan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/sched/cls_flower.c | 43 ++++++++++++++++++++++--------------------- + 1 file changed, 22 insertions(+), 21 deletions(-) + +--- a/net/sched/cls_flower.c ++++ b/net/sched/cls_flower.c +@@ -1327,46 +1327,46 @@ static int fl_change(struct net *net, st + if (err < 0) + goto errout; + +- if (!handle) { +- handle = 1; +- err = idr_alloc_u32(&head->handle_idr, fnew, &handle, +- INT_MAX, GFP_KERNEL); +- } else if (!fold) { +- /* user specifies a handle and it doesn't exist */ +- err = idr_alloc_u32(&head->handle_idr, fnew, &handle, +- handle, GFP_KERNEL); +- } +- if (err) +- goto errout; +- fnew->handle = handle; +- + if (tb[TCA_FLOWER_FLAGS]) { + fnew->flags = nla_get_u32(tb[TCA_FLOWER_FLAGS]); + + if (!tc_flags_valid(fnew->flags)) { + err = -EINVAL; +- goto errout_idr; ++ goto errout; + } + } + + err = fl_set_parms(net, tp, fnew, mask, base, tb, tca[TCA_RATE], ovr, + tp->chain->tmplt_priv, extack); + if (err) +- goto errout_idr; ++ goto errout; + + err = fl_check_assign_mask(head, fnew, fold, mask); + if (err) +- goto errout_idr; ++ goto errout; ++ ++ if (!handle) { ++ handle = 1; ++ err = idr_alloc_u32(&head->handle_idr, fnew, &handle, ++ INT_MAX, GFP_KERNEL); ++ } else if (!fold) { ++ /* user specifies a handle and it doesn't exist */ ++ err = idr_alloc_u32(&head->handle_idr, fnew, &handle, ++ handle, GFP_KERNEL); ++ } ++ if (err) ++ goto errout_mask; ++ fnew->handle = handle; + + if (!fold && __fl_lookup(fnew->mask, &fnew->mkey)) { + err = -EEXIST; +- goto errout_mask; ++ goto errout_idr; + } + + err = rhashtable_insert_fast(&fnew->mask->ht, &fnew->ht_node, + fnew->mask->filter_ht_params); + if (err) +- goto errout_mask; ++ goto errout_idr; + + if (!tc_skip_hw(fnew->flags)) { + err = fl_hw_replace_filter(tp, fnew, extack); +@@ -1405,12 +1405,13 @@ errout_mask_ht: + rhashtable_remove_fast(&fnew->mask->ht, &fnew->ht_node, + fnew->mask->filter_ht_params); + +-errout_mask: +- fl_mask_put(head, fnew->mask, false); +- + errout_idr: + if (!fold) + idr_remove(&head->handle_idr, fnew->handle); ++ ++errout_mask: ++ fl_mask_put(head, fnew->mask, false); ++ + errout: + tcf_exts_destroy(&fnew->exts); + kfree(fnew); diff --git a/queue-5.0/net-sit-fix-ubsan-undefined-behaviour-in-check_6rd.patch b/queue-5.0/net-sit-fix-ubsan-undefined-behaviour-in-check_6rd.patch new file mode 100644 index 00000000000..380fd9c8aa5 --- /dev/null +++ b/queue-5.0/net-sit-fix-ubsan-undefined-behaviour-in-check_6rd.patch @@ -0,0 +1,71 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Miaohe Lin +Date: Mon, 11 Mar 2019 16:29:32 +0800 +Subject: net: sit: fix UBSAN Undefined behaviour in check_6rd + +From: Miaohe Lin + +[ Upstream commit a843dc4ebaecd15fca1f4d35a97210f72ea1473b ] + +In func check_6rd,tunnel->ip6rd.relay_prefixlen may equal to +32,so UBSAN complain about it. + +UBSAN: Undefined behaviour in net/ipv6/sit.c:781:47 +shift exponent 32 is too large for 32-bit type 'unsigned int' +CPU: 6 PID: 20036 Comm: syz-executor.0 Not tainted 4.19.27 #2 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 +04/01/2014 +Call Trace: +__dump_stack lib/dump_stack.c:77 [inline] +dump_stack+0xca/0x13e lib/dump_stack.c:113 +ubsan_epilogue+0xe/0x81 lib/ubsan.c:159 +__ubsan_handle_shift_out_of_bounds+0x293/0x2e8 lib/ubsan.c:425 +check_6rd.constprop.9+0x433/0x4e0 net/ipv6/sit.c:781 +try_6rd net/ipv6/sit.c:806 [inline] +ipip6_tunnel_xmit net/ipv6/sit.c:866 [inline] +sit_tunnel_xmit+0x141c/0x2720 net/ipv6/sit.c:1033 +__netdev_start_xmit include/linux/netdevice.h:4300 [inline] +netdev_start_xmit include/linux/netdevice.h:4309 [inline] +xmit_one net/core/dev.c:3243 [inline] +dev_hard_start_xmit+0x17c/0x780 net/core/dev.c:3259 +__dev_queue_xmit+0x1656/0x2500 net/core/dev.c:3829 +neigh_output include/net/neighbour.h:501 [inline] +ip6_finish_output2+0xa36/0x2290 net/ipv6/ip6_output.c:120 +ip6_finish_output+0x3e7/0xa20 net/ipv6/ip6_output.c:154 +NF_HOOK_COND include/linux/netfilter.h:278 [inline] +ip6_output+0x1e2/0x720 net/ipv6/ip6_output.c:171 +dst_output include/net/dst.h:444 [inline] +ip6_local_out+0x99/0x170 net/ipv6/output_core.c:176 +ip6_send_skb+0x9d/0x2f0 net/ipv6/ip6_output.c:1697 +ip6_push_pending_frames+0xc0/0x100 net/ipv6/ip6_output.c:1717 +rawv6_push_pending_frames net/ipv6/raw.c:616 [inline] +rawv6_sendmsg+0x2435/0x3530 net/ipv6/raw.c:946 +inet_sendmsg+0xf8/0x5c0 net/ipv4/af_inet.c:798 +sock_sendmsg_nosec net/socket.c:621 [inline] +sock_sendmsg+0xc8/0x110 net/socket.c:631 +___sys_sendmsg+0x6cf/0x890 net/socket.c:2114 +__sys_sendmsg+0xf0/0x1b0 net/socket.c:2152 +do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290 +entry_SYSCALL_64_after_hwframe+0x49/0xbe + +Signed-off-by: linmiaohe +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv6/sit.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/net/ipv6/sit.c ++++ b/net/ipv6/sit.c +@@ -778,8 +778,9 @@ static bool check_6rd(struct ip_tunnel * + pbw0 = tunnel->ip6rd.prefixlen >> 5; + pbi0 = tunnel->ip6rd.prefixlen & 0x1f; + +- d = (ntohl(v6dst->s6_addr32[pbw0]) << pbi0) >> +- tunnel->ip6rd.relay_prefixlen; ++ d = tunnel->ip6rd.relay_prefixlen < 32 ? ++ (ntohl(v6dst->s6_addr32[pbw0]) << pbi0) >> ++ tunnel->ip6rd.relay_prefixlen : 0; + + pbi1 = pbi0 - tunnel->ip6rd.relay_prefixlen; + if (pbi1 > 0) diff --git a/queue-5.0/net-x25-fix-use-after-free-in-x25_device_event.patch b/queue-5.0/net-x25-fix-use-after-free-in-x25_device_event.patch new file mode 100644 index 00000000000..a537d737bdf --- /dev/null +++ b/queue-5.0/net-x25-fix-use-after-free-in-x25_device_event.patch @@ -0,0 +1,145 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Eric Dumazet +Date: Sun, 10 Mar 2019 09:07:14 -0700 +Subject: net/x25: fix use-after-free in x25_device_event() + +From: Eric Dumazet + +[ Upstream commit 95d6ebd53c79522bf9502dbc7e89e0d63f94dae4 ] + +In case of failure x25_connect() does a x25_neigh_put(x25->neighbour) +but forgets to clear x25->neighbour pointer, thus triggering use-after-free. + +Since the socket is visible in x25_list, we need to hold x25_list_lock +to protect the operation. + +syzbot report : + +BUG: KASAN: use-after-free in x25_kill_by_device net/x25/af_x25.c:217 [inline] +BUG: KASAN: use-after-free in x25_device_event+0x296/0x2b0 net/x25/af_x25.c:252 +Read of size 8 at addr ffff8880a030edd0 by task syz-executor003/7854 + +CPU: 0 PID: 7854 Comm: syz-executor003 Not tainted 5.0.0+ #97 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 +Call Trace: + __dump_stack lib/dump_stack.c:77 [inline] + dump_stack+0x172/0x1f0 lib/dump_stack.c:113 + print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 + kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 + __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 + x25_kill_by_device net/x25/af_x25.c:217 [inline] + x25_device_event+0x296/0x2b0 net/x25/af_x25.c:252 + notifier_call_chain+0xc7/0x240 kernel/notifier.c:93 + __raw_notifier_call_chain kernel/notifier.c:394 [inline] + raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401 + call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739 + call_netdevice_notifiers_extack net/core/dev.c:1751 [inline] + call_netdevice_notifiers net/core/dev.c:1765 [inline] + __dev_notify_flags+0x1e9/0x2c0 net/core/dev.c:7607 + dev_change_flags+0x10d/0x170 net/core/dev.c:7643 + dev_ifsioc+0x2b0/0x940 net/core/dev_ioctl.c:237 + dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:488 + sock_do_ioctl+0x1bd/0x300 net/socket.c:995 + sock_ioctl+0x32b/0x610 net/socket.c:1096 + vfs_ioctl fs/ioctl.c:46 [inline] + file_ioctl fs/ioctl.c:509 [inline] + do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696 + ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 + __do_sys_ioctl fs/ioctl.c:720 [inline] + __se_sys_ioctl fs/ioctl.c:718 [inline] + __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 + do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 + entry_SYSCALL_64_after_hwframe+0x49/0xbe +RIP: 0033:0x4467c9 +Code: e8 0c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00 +RSP: 002b:00007fdbea222d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 +RAX: ffffffffffffffda RBX: 00000000006dbc58 RCX: 00000000004467c9 +RDX: 0000000020000340 RSI: 0000000000008914 RDI: 0000000000000003 +RBP: 00000000006dbc50 R08: 00007fdbea223700 R09: 0000000000000000 +R10: 00007fdbea223700 R11: 0000000000000246 R12: 00000000006dbc5c +R13: 6000030030626669 R14: 0000000000000000 R15: 0000000030626669 + +Allocated by task 7843: + save_stack+0x45/0xd0 mm/kasan/common.c:73 + set_track mm/kasan/common.c:85 [inline] + __kasan_kmalloc mm/kasan/common.c:495 [inline] + __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:468 + kasan_kmalloc+0x9/0x10 mm/kasan/common.c:509 + kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615 + kmalloc include/linux/slab.h:545 [inline] + x25_link_device_up+0x46/0x3f0 net/x25/x25_link.c:249 + x25_device_event+0x116/0x2b0 net/x25/af_x25.c:242 + notifier_call_chain+0xc7/0x240 kernel/notifier.c:93 + __raw_notifier_call_chain kernel/notifier.c:394 [inline] + raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401 + call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739 + call_netdevice_notifiers_extack net/core/dev.c:1751 [inline] + call_netdevice_notifiers net/core/dev.c:1765 [inline] + __dev_notify_flags+0x121/0x2c0 net/core/dev.c:7605 + dev_change_flags+0x10d/0x170 net/core/dev.c:7643 + dev_ifsioc+0x2b0/0x940 net/core/dev_ioctl.c:237 + dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:488 + sock_do_ioctl+0x1bd/0x300 net/socket.c:995 + sock_ioctl+0x32b/0x610 net/socket.c:1096 + vfs_ioctl fs/ioctl.c:46 [inline] + file_ioctl fs/ioctl.c:509 [inline] + do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696 + ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 + __do_sys_ioctl fs/ioctl.c:720 [inline] + __se_sys_ioctl fs/ioctl.c:718 [inline] + __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 + do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 + entry_SYSCALL_64_after_hwframe+0x49/0xbe + +Freed by task 7865: + save_stack+0x45/0xd0 mm/kasan/common.c:73 + set_track mm/kasan/common.c:85 [inline] + __kasan_slab_free+0x102/0x150 mm/kasan/common.c:457 + kasan_slab_free+0xe/0x10 mm/kasan/common.c:465 + __cache_free mm/slab.c:3494 [inline] + kfree+0xcf/0x230 mm/slab.c:3811 + x25_neigh_put include/net/x25.h:253 [inline] + x25_connect+0x8d8/0xde0 net/x25/af_x25.c:824 + __sys_connect+0x266/0x330 net/socket.c:1685 + __do_sys_connect net/socket.c:1696 [inline] + __se_sys_connect net/socket.c:1693 [inline] + __x64_sys_connect+0x73/0xb0 net/socket.c:1693 + do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 + entry_SYSCALL_64_after_hwframe+0x49/0xbe + +The buggy address belongs to the object at ffff8880a030edc0 + which belongs to the cache kmalloc-256 of size 256 +The buggy address is located 16 bytes inside of + 256-byte region [ffff8880a030edc0, ffff8880a030eec0) +The buggy address belongs to the page: +page:ffffea000280c380 count:1 mapcount:0 mapping:ffff88812c3f07c0 index:0x0 +flags: 0x1fffc0000000200(slab) +raw: 01fffc0000000200 ffffea0002806788 ffffea00027f0188 ffff88812c3f07c0 +raw: 0000000000000000 ffff8880a030e000 000000010000000c 0000000000000000 +page dumped because: kasan: bad access detected + +Signed-off-by: Eric Dumazet +Reported-by: syzbot+04babcefcd396fabec37@syzkaller.appspotmail.com +Cc: andrew hendry +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/x25/af_x25.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/net/x25/af_x25.c ++++ b/net/x25/af_x25.c +@@ -820,8 +820,12 @@ static int x25_connect(struct socket *so + sock->state = SS_CONNECTED; + rc = 0; + out_put_neigh: +- if (rc) ++ if (rc) { ++ read_lock_bh(&x25_list_lock); + x25_neigh_put(x25->neighbour); ++ x25->neighbour = NULL; ++ read_unlock_bh(&x25_list_lock); ++ } + out_put_route: + x25_route_put(rt); + out: diff --git a/queue-5.0/net-x25-reset-state-in-x25_connect.patch b/queue-5.0/net-x25-reset-state-in-x25_connect.patch new file mode 100644 index 00000000000..b7ae0860f65 --- /dev/null +++ b/queue-5.0/net-x25-reset-state-in-x25_connect.patch @@ -0,0 +1,81 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Eric Dumazet +Date: Mon, 11 Mar 2019 13:48:44 -0700 +Subject: net/x25: reset state in x25_connect() + +From: Eric Dumazet + +[ Upstream commit ee74d0bd4325efb41e38affe5955f920ed973f23 ] + +In case x25_connect() fails and frees the socket neighbour, +we also need to undo the change done to x25->state. + +Before my last bug fix, we had use-after-free so this +patch fixes a latent bug. + +syzbot report : + +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: 1 PID: 16137 Comm: syz-executor.1 Not tainted 5.0.0+ #117 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 +RIP: 0010:x25_write_internal+0x1e8/0xdf0 net/x25/x25_subr.c:173 +Code: 00 40 88 b5 e0 fe ff ff 0f 85 01 0b 00 00 48 8b 8b 80 04 00 00 48 ba 00 00 00 00 00 fc ff df 48 8d 79 1c 48 89 fe 48 c1 ee 03 <0f> b6 34 16 48 89 fa 83 e2 07 83 c2 03 40 38 f2 7c 09 40 84 f6 0f +RSP: 0018:ffff888076717a08 EFLAGS: 00010207 +RAX: ffff88805f2f2292 RBX: ffff8880a0ae6000 RCX: 0000000000000000 +kobject: 'loop5' (0000000018d0d0ee): kobject_uevent_env +RDX: dffffc0000000000 RSI: 0000000000000003 RDI: 000000000000001c +RBP: ffff888076717b40 R08: ffff8880950e0580 R09: ffffed100be5e46d +R10: ffffed100be5e46c R11: ffff88805f2f2363 R12: ffff888065579840 +kobject: 'loop5' (0000000018d0d0ee): fill_kobj_path: path = '/devices/virtual/block/loop5' +R13: 1ffff1100ece2f47 R14: 0000000000000013 R15: 0000000000000013 +FS: 00007fb88cf43700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007f9a42a41028 CR3: 0000000087a67000 CR4: 00000000001406e0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + x25_release+0xd0/0x340 net/x25/af_x25.c:658 + __sock_release+0xd3/0x2b0 net/socket.c:579 + sock_close+0x1b/0x30 net/socket.c:1162 + __fput+0x2df/0x8d0 fs/file_table.c:278 + ____fput+0x16/0x20 fs/file_table.c:309 + task_work_run+0x14a/0x1c0 kernel/task_work.c:113 + get_signal+0x1961/0x1d50 kernel/signal.c:2388 + do_signal+0x87/0x1940 arch/x86/kernel/signal.c:816 + exit_to_usermode_loop+0x244/0x2c0 arch/x86/entry/common.c:162 + prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] + syscall_return_slowpath arch/x86/entry/common.c:268 [inline] + do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293 + entry_SYSCALL_64_after_hwframe+0x49/0xbe +RIP: 0033:0x457f29 +Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 +RSP: 002b:00007fb88cf42c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a +RAX: fffffffffffffe00 RBX: 0000000000000003 RCX: 0000000000457f29 +RDX: 0000000000000012 RSI: 0000000020000080 RDI: 0000000000000004 +RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb88cf436d4 +R13: 00000000004be462 R14: 00000000004cec98 R15: 00000000ffffffff +Modules linked in: + +Fixes: 95d6ebd53c79 ("net/x25: fix use-after-free in x25_device_event()") +Signed-off-by: Eric Dumazet +Cc: andrew hendry +Reported-by: syzbot +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/x25/af_x25.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/net/x25/af_x25.c ++++ b/net/x25/af_x25.c +@@ -825,6 +825,7 @@ out_put_neigh: + x25_neigh_put(x25->neighbour); + x25->neighbour = NULL; + read_unlock_bh(&x25_list_lock); ++ x25->state = X25_STATE_0; + } + out_put_route: + x25_route_put(rt); diff --git a/queue-5.0/pptp-dst_release-sk_dst_cache-in-pptp_sock_destruct.patch b/queue-5.0/pptp-dst_release-sk_dst_cache-in-pptp_sock_destruct.patch new file mode 100644 index 00000000000..d7906a30871 --- /dev/null +++ b/queue-5.0/pptp-dst_release-sk_dst_cache-in-pptp_sock_destruct.patch @@ -0,0 +1,46 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Xin Long +Date: Wed, 13 Mar 2019 17:00:48 +0800 +Subject: pptp: dst_release sk_dst_cache in pptp_sock_destruct + +From: Xin Long + +[ Upstream commit 9417d81f4f8adfe20a12dd1fadf73a618cbd945d ] + +sk_setup_caps() is called to set sk->sk_dst_cache in pptp_connect, +so we have to dst_release(sk->sk_dst_cache) in pptp_sock_destruct, +otherwise, the dst refcnt will leak. + +It can be reproduced by this syz log: + + r1 = socket$pptp(0x18, 0x1, 0x2) + bind$pptp(r1, &(0x7f0000000100)={0x18, 0x2, {0x0, @local}}, 0x1e) + connect$pptp(r1, &(0x7f0000000000)={0x18, 0x2, {0x3, @remote}}, 0x1e) + +Consecutive dmesg warnings will occur: + + unregister_netdevice: waiting for lo to become free. Usage count = 1 + +v1->v2: + - use rcu_dereference_protected() instead of rcu_dereference_check(), + as suggested by Eric. + +Fixes: 00959ade36ac ("PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)") +Reported-by: Xiumei Mu +Signed-off-by: Xin Long +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ppp/pptp.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/ppp/pptp.c ++++ b/drivers/net/ppp/pptp.c +@@ -532,6 +532,7 @@ static void pptp_sock_destruct(struct so + pppox_unbind_sock(sk); + } + skb_queue_purge(&sk->sk_receive_queue); ++ dst_release(rcu_dereference_protected(sk->sk_dst_cache, 1)); + } + + static int pptp_create(struct net *net, struct socket *sock, int kern) diff --git a/queue-5.0/ravb-decrease-txfifo-depth-of-q3-and-q2-to-one.patch b/queue-5.0/ravb-decrease-txfifo-depth-of-q3-and-q2-to-one.patch new file mode 100644 index 00000000000..13babc0a7d3 --- /dev/null +++ b/queue-5.0/ravb-decrease-txfifo-depth-of-q3-and-q2-to-one.patch @@ -0,0 +1,43 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Masaru Nagai +Date: Thu, 7 Mar 2019 11:24:47 +0100 +Subject: ravb: Decrease TxFIFO depth of Q3 and Q2 to one + +From: Masaru Nagai + +[ Upstream commit ae9819e339b451da7a86ab6fe38ecfcb6814e78a ] + +Hardware has the CBS (Credit Based Shaper) which affects only Q3 +and Q2. When updating the CBS settings, even if the driver does so +after waiting for Tx DMA finished, there is a possibility that frame +data still remains in TxFIFO. + +To avoid this, decrease TxFIFO depth of Q3 and Q2 to one. + +This patch has been exercised this using netperf TCP_MAERTS, TCP_STREAM +and UDP_STREAM tests run on an Ebisu board. No performance change was +detected, outside of noise in the tests, both in terms of throughput and +CPU utilisation. + +Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") +Signed-off-by: Masaru Nagai +Signed-off-by: Kazuya Mizuguchi +[simon: updated changelog] +Signed-off-by: Simon Horman +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/renesas/ravb_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/renesas/ravb_main.c ++++ b/drivers/net/ethernet/renesas/ravb_main.c +@@ -458,7 +458,7 @@ static int ravb_dmac_init(struct net_dev + RCR_EFFS | RCR_ENCF | RCR_ETS0 | RCR_ESF | 0x18000000, RCR); + + /* Set FIFO size */ +- ravb_write(ndev, TGC_TQP_AVBMODE1 | 0x00222200, TGC); ++ ravb_write(ndev, TGC_TQP_AVBMODE1 | 0x00112200, TGC); + + /* Timestamp enable */ + ravb_write(ndev, TCCR_TFEN, TCCR); diff --git a/queue-5.0/route-set-the-deleted-fnhe-fnhe_daddr-to-0-in-ip_del_fnhe-to-fix-a-race.patch b/queue-5.0/route-set-the-deleted-fnhe-fnhe_daddr-to-0-in-ip_del_fnhe-to-fix-a-race.patch new file mode 100644 index 00000000000..85a315cc2ac --- /dev/null +++ b/queue-5.0/route-set-the-deleted-fnhe-fnhe_daddr-to-0-in-ip_del_fnhe-to-fix-a-race.patch @@ -0,0 +1,55 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Xin Long +Date: Fri, 8 Mar 2019 14:50:54 +0800 +Subject: route: set the deleted fnhe fnhe_daddr to 0 in ip_del_fnhe to fix a race + +From: Xin Long + +[ Upstream commit ee60ad219f5c7c4fb2f047f88037770063ef785f ] + +The race occurs in __mkroute_output() when 2 threads lookup a dst: + + CPU A CPU B + find_exception() + find_exception() [fnhe expires] + ip_del_fnhe() [fnhe is deleted] + rt_bind_exception() + +In rt_bind_exception() it will bind a deleted fnhe with the new dst, and +this dst will get no chance to be freed. It causes a dev defcnt leak and +consecutive dmesg warnings: + + unregister_netdevice: waiting for ethX to become free. Usage count = 1 + +Especially thanks Jon to identify the issue. + +This patch fixes it by setting fnhe_daddr to 0 in ip_del_fnhe() to stop +binding the deleted fnhe with a new dst when checking fnhe's fnhe_daddr +and daddr in rt_bind_exception(). + +It works as both ip_del_fnhe() and rt_bind_exception() are protected by +fnhe_lock and the fhne is freed by kfree_rcu(). + +Fixes: deed49df7390 ("route: check and remove route cache when we get route") +Signed-off-by: Jon Maxwell +Signed-off-by: Xin Long +Reviewed-by: David Ahern +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/route.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/net/ipv4/route.c ++++ b/net/ipv4/route.c +@@ -1303,6 +1303,10 @@ static void ip_del_fnhe(struct fib_nh *n + if (fnhe->fnhe_daddr == daddr) { + rcu_assign_pointer(*fnhe_p, rcu_dereference_protected( + fnhe->fnhe_next, lockdep_is_held(&fnhe_lock))); ++ /* set fnhe_daddr to 0 to ensure it won't bind with ++ * new dsts in rt_bind_exception(). ++ */ ++ fnhe->fnhe_daddr = 0; + fnhe_flush_routes(fnhe); + kfree_rcu(fnhe, rcu); + break; diff --git a/queue-5.0/rxrpc-fix-client-call-queueing-waiting-for-channel.patch b/queue-5.0/rxrpc-fix-client-call-queueing-waiting-for-channel.patch new file mode 100644 index 00000000000..7db4e2270df --- /dev/null +++ b/queue-5.0/rxrpc-fix-client-call-queueing-waiting-for-channel.patch @@ -0,0 +1,49 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: David Howells +Date: Sat, 9 Mar 2019 00:29:58 +0000 +Subject: rxrpc: Fix client call queueing, waiting for channel + +From: David Howells + +[ Upstream commit 69ffaebb90369ce08657b5aea4896777b9d6e8fc ] + +rxrpc_get_client_conn() adds a new call to the front of the waiting_calls +queue if the connection it's going to use already exists. This is bad as +it allows calls to get starved out. + +Fix this by adding to the tail instead. + +Also change the other enqueue point in the same function to put it on the +front (ie. when we have a new connection). This makes the point that in +the case of a new connection the new call goes at the front (though it +doesn't actually matter since the queue should be unoccupied). + +Fixes: 45025bceef17 ("rxrpc: Improve management and caching of client connection objects") +Signed-off-by: David Howells +Reviewed-by: Marc Dionne +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/rxrpc/conn_client.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/rxrpc/conn_client.c ++++ b/net/rxrpc/conn_client.c +@@ -353,7 +353,7 @@ static int rxrpc_get_client_conn(struct + * normally have to take channel_lock but we do this before anyone else + * can see the connection. + */ +- list_add_tail(&call->chan_wait_link, &candidate->waiting_calls); ++ list_add(&call->chan_wait_link, &candidate->waiting_calls); + + if (cp->exclusive) { + call->conn = candidate; +@@ -432,7 +432,7 @@ found_extant_conn: + call->conn = conn; + call->security_ix = conn->security_ix; + call->service_id = conn->service_id; +- list_add(&call->chan_wait_link, &conn->waiting_calls); ++ list_add_tail(&call->chan_wait_link, &conn->waiting_calls); + spin_unlock(&conn->channel_lock); + _leave(" = 0 [extant %d]", conn->debug_id); + return 0; diff --git a/queue-5.0/sctp-remove-sched-init-from-sctp_stream_init.patch b/queue-5.0/sctp-remove-sched-init-from-sctp_stream_init.patch new file mode 100644 index 00000000000..6e540d9d71a --- /dev/null +++ b/queue-5.0/sctp-remove-sched-init-from-sctp_stream_init.patch @@ -0,0 +1,46 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Xin Long +Date: Fri, 8 Mar 2019 15:49:16 +0800 +Subject: sctp: remove sched init from sctp_stream_init + +From: Xin Long + +[ Upstream commit 2e990dfd13974d9eae493006f42ffb48707970ef ] + +syzbot reported a NULL-ptr deref caused by that sched->init() in +sctp_stream_init() set stream->rr_next = NULL. + + kasan: GPF could be caused by NULL-ptr deref or user memory access + RIP: 0010:sctp_sched_rr_dequeue+0xd3/0x170 net/sctp/stream_sched_rr.c:141 + Call Trace: + sctp_outq_dequeue_data net/sctp/outqueue.c:90 [inline] + sctp_outq_flush_data net/sctp/outqueue.c:1079 [inline] + sctp_outq_flush+0xba2/0x2790 net/sctp/outqueue.c:1205 + +All sched info is saved in sout->ext now, in sctp_stream_init() +sctp_stream_alloc_out() will not change it, there's no need to +call sched->init() again, since sctp_outq_init() has already +done it. + +Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") +Reported-by: syzbot+4c9934f20522c0efd657@syzkaller.appspotmail.com +Signed-off-by: Xin Long +Acked-by: Neil Horman +Acked-by: Marcelo Ricardo Leitner +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/sctp/stream.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/net/sctp/stream.c ++++ b/net/sctp/stream.c +@@ -230,8 +230,6 @@ int sctp_stream_init(struct sctp_stream + for (i = 0; i < stream->outcnt; i++) + SCTP_SO(stream, i)->state = SCTP_STREAM_OPEN; + +- sched->init(stream); +- + in: + sctp_stream_interleave_init(stream); + if (!incnt) diff --git a/queue-5.0/series b/queue-5.0/series new file mode 100644 index 00000000000..5fae6df2b52 --- /dev/null +++ b/queue-5.0/series @@ -0,0 +1,30 @@ +connector-fix-unsafe-usage-of-real_parent.patch +fou-fou6-avoid-uninit-value-in-gue_err-and-gue6_err.patch +gro_cells-make-sure-device-is-up-in-gro_cells_receive.patch +ipv4-route-fail-early-when-inet-dev-is-missing.patch +l2tp-fix-infoleak-in-l2tp_ip6_recvmsg.patch +lan743x-fix-rx-kernel-panic.patch +lan743x-fix-tx-stall-issue.patch +net-hns3-add-dma_rmb-for-rx-description.patch +net-hsr-fix-memory-leak-in-hsr_dev_finalize.patch +net-hsr-fix-possible-crash-in-add_timer.patch +net-sit-fix-ubsan-undefined-behaviour-in-check_6rd.patch +net-x25-fix-use-after-free-in-x25_device_event.patch +net-x25-reset-state-in-x25_connect.patch +pptp-dst_release-sk_dst_cache-in-pptp_sock_destruct.patch +ravb-decrease-txfifo-depth-of-q3-and-q2-to-one.patch +route-set-the-deleted-fnhe-fnhe_daddr-to-0-in-ip_del_fnhe-to-fix-a-race.patch +rxrpc-fix-client-call-queueing-waiting-for-channel.patch +sctp-remove-sched-init-from-sctp_stream_init.patch +tcp-do-not-report-tcp_cm_inq-of-0-for-closed-connections.patch +tcp-don-t-access-tcp_skb_cb-before-initializing-it.patch +tcp-handle-inet_csk_reqsk_queue_add-failures.patch +vxlan-fix-gro-cells-race-condition-between-receive-and-link-delete.patch +vxlan-test-dev-flags-iff_up-before-calling-gro_cells_receive.patch +net-mlx4_core-fix-reset-flow-when-in-command-polling-mode.patch +net-mlx4_core-fix-locking-in-sriov-mode-when-switching-between-events-and-polling.patch +net-mlx4_core-fix-qp-mtt-size-calculation.patch +net-dsa-mv88e6xxx-set-correct-interface-mode-for-cpu-dsa-ports.patch +net-hns3-fix-to-stop-multiple-hns-reset-due-to-the-aer-changes.patch +vsock-virtio-fix-kernel-panic-from-virtio_transport_reset_no_sock.patch +net-sched-flower-insert-new-filter-to-idr-after-setting-its-mask.patch diff --git a/queue-5.0/tcp-do-not-report-tcp_cm_inq-of-0-for-closed-connections.patch b/queue-5.0/tcp-do-not-report-tcp_cm_inq-of-0-for-closed-connections.patch new file mode 100644 index 00000000000..4c7d5c7a5f9 --- /dev/null +++ b/queue-5.0/tcp-do-not-report-tcp_cm_inq-of-0-for-closed-connections.patch @@ -0,0 +1,46 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Soheil Hassas Yeganeh +Date: Wed, 6 Mar 2019 13:01:36 -0500 +Subject: tcp: do not report TCP_CM_INQ of 0 for closed connections + +From: Soheil Hassas Yeganeh + +[ Upstream commit 6466e715651f9f358e60c5ea4880e4731325827f ] + +Returning 0 as inq to userspace indicates there is no more data to +read, and the application needs to wait for EPOLLIN. For a connection +that has received FIN from the remote peer, however, the application +must continue reading until getting EOF (return value of 0 +from tcp_recvmsg) or an error, if edge-triggered epoll (EPOLLET) is +being used. Otherwise, the application will never receive a new +EPOLLIN, since there is no epoll edge after the FIN. + +Return 1 when there is no data left on the queue but the +connection has received FIN, so that the applications continue +reading. + +Fixes: b75eba76d3d72 (tcp: send in-queue bytes in cmsg upon read) +Signed-off-by: Soheil Hassas Yeganeh +Acked-by: Neal Cardwell +Signed-off-by: Eric Dumazet +Acked-by: Yuchung Cheng +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/tcp.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/net/ipv4/tcp.c ++++ b/net/ipv4/tcp.c +@@ -1914,6 +1914,11 @@ static int tcp_inq_hint(struct sock *sk) + inq = tp->rcv_nxt - tp->copied_seq; + release_sock(sk); + } ++ /* After receiving a FIN, tell the user-space to continue reading ++ * by returning a non-zero inq. ++ */ ++ if (inq == 0 && sock_flag(sk, SOCK_DONE)) ++ inq = 1; + return inq; + } + diff --git a/queue-5.0/tcp-don-t-access-tcp_skb_cb-before-initializing-it.patch b/queue-5.0/tcp-don-t-access-tcp_skb_cb-before-initializing-it.patch new file mode 100644 index 00000000000..dee0185bbf0 --- /dev/null +++ b/queue-5.0/tcp-don-t-access-tcp_skb_cb-before-initializing-it.patch @@ -0,0 +1,52 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Christoph Paasch +Date: Mon, 11 Mar 2019 11:41:05 -0700 +Subject: tcp: Don't access TCP_SKB_CB before initializing it + +From: Christoph Paasch + +[ Upstream commit f2feaefdabb0a6253aa020f65e7388f07a9ed47c ] + +Since commit eeea10b83a13 ("tcp: add +tcp_v4_fill_cb()/tcp_v4_restore_cb()"), tcp_vX_fill_cb is only called +after tcp_filter(). That means, TCP_SKB_CB(skb)->end_seq still points to +the IP-part of the cb. + +We thus should not mock with it, as this can trigger bugs (thanks +syzkaller): +[ 12.349396] ================================================================== +[ 12.350188] BUG: KASAN: slab-out-of-bounds in ip6_datagram_recv_specific_ctl+0x19b3/0x1a20 +[ 12.351035] Read of size 1 at addr ffff88006adbc208 by task test_ip6_datagr/1799 + +Setting end_seq is actually no more necessary in tcp_filter as it gets +initialized later on in tcp_vX_fill_cb. + +Cc: Eric Dumazet +Fixes: eeea10b83a13 ("tcp: add tcp_v4_fill_cb()/tcp_v4_restore_cb()") +Signed-off-by: Christoph Paasch +Signed-off-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/tcp_ipv4.c | 9 +-------- + 1 file changed, 1 insertion(+), 8 deletions(-) + +--- a/net/ipv4/tcp_ipv4.c ++++ b/net/ipv4/tcp_ipv4.c +@@ -1734,15 +1734,8 @@ EXPORT_SYMBOL(tcp_add_backlog); + int tcp_filter(struct sock *sk, struct sk_buff *skb) + { + struct tcphdr *th = (struct tcphdr *)skb->data; +- unsigned int eaten = skb->len; +- int err; + +- err = sk_filter_trim_cap(sk, skb, th->doff * 4); +- if (!err) { +- eaten -= skb->len; +- TCP_SKB_CB(skb)->end_seq -= eaten; +- } +- return err; ++ return sk_filter_trim_cap(sk, skb, th->doff * 4); + } + EXPORT_SYMBOL(tcp_filter); + diff --git a/queue-5.0/tcp-handle-inet_csk_reqsk_queue_add-failures.patch b/queue-5.0/tcp-handle-inet_csk_reqsk_queue_add-failures.patch new file mode 100644 index 00000000000..35b07342ef8 --- /dev/null +++ b/queue-5.0/tcp-handle-inet_csk_reqsk_queue_add-failures.patch @@ -0,0 +1,66 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Guillaume Nault +Date: Fri, 8 Mar 2019 22:09:47 +0100 +Subject: tcp: handle inet_csk_reqsk_queue_add() failures + +From: Guillaume Nault + +[ Upstream commit 9d3e1368bb45893a75a5dfb7cd21fdebfa6b47af ] + +Commit 7716682cc58e ("tcp/dccp: fix another race at listener +dismantle") let inet_csk_reqsk_queue_add() fail, and adjusted +{tcp,dccp}_check_req() accordingly. However, TFO and syncookies +weren't modified, thus leaking allocated resources on error. + +Contrary to tcp_check_req(), in both syncookies and TFO cases, +we need to drop the request socket. Also, since the child socket is +created with inet_csk_clone_lock(), we have to unlock it and drop an +extra reference (->sk_refcount is initially set to 2 and +inet_csk_reqsk_queue_add() drops only one ref). + +For TFO, we also need to revert the work done by tcp_try_fastopen() +(with reqsk_fastopen_remove()). + +Fixes: 7716682cc58e ("tcp/dccp: fix another race at listener dismantle") +Signed-off-by: Guillaume Nault +Signed-off-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/syncookies.c | 7 ++++++- + net/ipv4/tcp_input.c | 8 +++++++- + 2 files changed, 13 insertions(+), 2 deletions(-) + +--- a/net/ipv4/syncookies.c ++++ b/net/ipv4/syncookies.c +@@ -216,7 +216,12 @@ struct sock *tcp_get_cookie_sock(struct + refcount_set(&req->rsk_refcnt, 1); + tcp_sk(child)->tsoffset = tsoff; + sock_rps_save_rxhash(child, skb); +- inet_csk_reqsk_queue_add(sk, req, child); ++ if (!inet_csk_reqsk_queue_add(sk, req, child)) { ++ bh_unlock_sock(child); ++ sock_put(child); ++ child = NULL; ++ reqsk_put(req); ++ } + } else { + reqsk_free(req); + } +--- a/net/ipv4/tcp_input.c ++++ b/net/ipv4/tcp_input.c +@@ -6519,7 +6519,13 @@ int tcp_conn_request(struct request_sock + af_ops->send_synack(fastopen_sk, dst, &fl, req, + &foc, TCP_SYNACK_FASTOPEN); + /* Add the child socket directly into the accept queue */ +- inet_csk_reqsk_queue_add(sk, req, fastopen_sk); ++ if (!inet_csk_reqsk_queue_add(sk, req, fastopen_sk)) { ++ reqsk_fastopen_remove(fastopen_sk, req, false); ++ bh_unlock_sock(fastopen_sk); ++ sock_put(fastopen_sk); ++ reqsk_put(req); ++ goto drop; ++ } + sk->sk_data_ready(sk); + bh_unlock_sock(fastopen_sk); + sock_put(fastopen_sk); diff --git a/queue-5.0/vsock-virtio-fix-kernel-panic-from-virtio_transport_reset_no_sock.patch b/queue-5.0/vsock-virtio-fix-kernel-panic-from-virtio_transport_reset_no_sock.patch new file mode 100644 index 00000000000..d94af5b9ef4 --- /dev/null +++ b/queue-5.0/vsock-virtio-fix-kernel-panic-from-virtio_transport_reset_no_sock.patch @@ -0,0 +1,101 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: "Adalbert Lazăr" +Date: Wed, 6 Mar 2019 12:13:53 +0200 +Subject: vsock/virtio: fix kernel panic from virtio_transport_reset_no_sock + +From: "Adalbert Lazăr" + +[ Upstream commit 4c404ce23358d5d8fbdeb7a6021a9b33d3c3c167 ] + +Previous to commit 22b5c0b63f32 ("vsock/virtio: fix kernel panic +after device hot-unplug"), vsock_core_init() was called from +virtio_vsock_probe(). Now, virtio_transport_reset_no_sock() can be called +before vsock_core_init() has the chance to run. + +[Wed Feb 27 14:17:09 2019] BUG: unable to handle kernel NULL pointer dereference at 0000000000000110 +[Wed Feb 27 14:17:09 2019] #PF error: [normal kernel read fault] +[Wed Feb 27 14:17:09 2019] PGD 0 P4D 0 +[Wed Feb 27 14:17:09 2019] Oops: 0000 [#1] SMP PTI +[Wed Feb 27 14:17:09 2019] CPU: 3 PID: 59 Comm: kworker/3:1 Not tainted 5.0.0-rc7-390-generic-hvi #390 +[Wed Feb 27 14:17:09 2019] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 +[Wed Feb 27 14:17:09 2019] Workqueue: virtio_vsock virtio_transport_rx_work [vmw_vsock_virtio_transport] +[Wed Feb 27 14:17:09 2019] RIP: 0010:virtio_transport_reset_no_sock+0x8c/0xc0 [vmw_vsock_virtio_transport_common] +[Wed Feb 27 14:17:09 2019] Code: 35 8b 4f 14 48 8b 57 08 31 f6 44 8b 4f 10 44 8b 07 48 8d 7d c8 e8 84 f8 ff ff 48 85 c0 48 89 c3 74 2a e8 f7 31 03 00 48 89 df <48> 8b 80 10 01 00 00 e8 68 fb 69 ed 48 8b 75 f0 65 48 33 34 25 28 +[Wed Feb 27 14:17:09 2019] RSP: 0018:ffffb42701ab7d40 EFLAGS: 00010282 +[Wed Feb 27 14:17:09 2019] RAX: 0000000000000000 RBX: ffff9d79637ee080 RCX: 0000000000000003 +[Wed Feb 27 14:17:09 2019] RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff9d79637ee080 +[Wed Feb 27 14:17:09 2019] RBP: ffffb42701ab7d78 R08: ffff9d796fae70e0 R09: ffff9d796f403500 +[Wed Feb 27 14:17:09 2019] R10: ffffb42701ab7d90 R11: 0000000000000000 R12: ffff9d7969d09240 +[Wed Feb 27 14:17:09 2019] R13: ffff9d79624e6840 R14: ffff9d7969d09318 R15: ffff9d796d48ff80 +[Wed Feb 27 14:17:09 2019] FS: 0000000000000000(0000) GS:ffff9d796fac0000(0000) knlGS:0000000000000000 +[Wed Feb 27 14:17:09 2019] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[Wed Feb 27 14:17:09 2019] CR2: 0000000000000110 CR3: 0000000427f22000 CR4: 00000000000006e0 +[Wed Feb 27 14:17:09 2019] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[Wed Feb 27 14:17:09 2019] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[Wed Feb 27 14:17:09 2019] Call Trace: +[Wed Feb 27 14:17:09 2019] virtio_transport_recv_pkt+0x63/0x820 [vmw_vsock_virtio_transport_common] +[Wed Feb 27 14:17:09 2019] ? kfree+0x17e/0x190 +[Wed Feb 27 14:17:09 2019] ? detach_buf_split+0x145/0x160 +[Wed Feb 27 14:17:09 2019] ? __switch_to_asm+0x40/0x70 +[Wed Feb 27 14:17:09 2019] virtio_transport_rx_work+0xa0/0x106 [vmw_vsock_virtio_transport] +[Wed Feb 27 14:17:09 2019] NET: Registered protocol family 40 +[Wed Feb 27 14:17:09 2019] process_one_work+0x167/0x410 +[Wed Feb 27 14:17:09 2019] worker_thread+0x4d/0x460 +[Wed Feb 27 14:17:09 2019] kthread+0x105/0x140 +[Wed Feb 27 14:17:09 2019] ? rescuer_thread+0x360/0x360 +[Wed Feb 27 14:17:09 2019] ? kthread_destroy_worker+0x50/0x50 +[Wed Feb 27 14:17:09 2019] ret_from_fork+0x35/0x40 +[Wed Feb 27 14:17:09 2019] Modules linked in: vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common input_leds vsock serio_raw i2c_piix4 mac_hid qemu_fw_cfg autofs4 cirrus ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops virtio_net psmouse drm net_failover pata_acpi virtio_blk failover floppy + +Fixes: 22b5c0b63f32 ("vsock/virtio: fix kernel panic after device hot-unplug") +Reported-by: Alexandru Herghelegiu +Signed-off-by: Adalbert Lazăr +Co-developed-by: Stefan Hajnoczi +Reviewed-by: Stefan Hajnoczi +Reviewed-by: Stefano Garzarella +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/virtio_transport_common.c | 22 +++++++++++++++------- + 1 file changed, 15 insertions(+), 7 deletions(-) + +--- a/net/vmw_vsock/virtio_transport_common.c ++++ b/net/vmw_vsock/virtio_transport_common.c +@@ -662,6 +662,8 @@ static int virtio_transport_reset(struct + */ + static int virtio_transport_reset_no_sock(struct virtio_vsock_pkt *pkt) + { ++ const struct virtio_transport *t; ++ struct virtio_vsock_pkt *reply; + struct virtio_vsock_pkt_info info = { + .op = VIRTIO_VSOCK_OP_RST, + .type = le16_to_cpu(pkt->hdr.type), +@@ -672,15 +674,21 @@ static int virtio_transport_reset_no_soc + if (le16_to_cpu(pkt->hdr.op) == VIRTIO_VSOCK_OP_RST) + return 0; + +- pkt = virtio_transport_alloc_pkt(&info, 0, +- le64_to_cpu(pkt->hdr.dst_cid), +- le32_to_cpu(pkt->hdr.dst_port), +- le64_to_cpu(pkt->hdr.src_cid), +- le32_to_cpu(pkt->hdr.src_port)); +- if (!pkt) ++ reply = virtio_transport_alloc_pkt(&info, 0, ++ le64_to_cpu(pkt->hdr.dst_cid), ++ le32_to_cpu(pkt->hdr.dst_port), ++ le64_to_cpu(pkt->hdr.src_cid), ++ le32_to_cpu(pkt->hdr.src_port)); ++ if (!reply) + return -ENOMEM; + +- return virtio_transport_get_ops()->send_pkt(pkt); ++ t = virtio_transport_get_ops(); ++ if (!t) { ++ virtio_transport_free_pkt(reply); ++ return -ENOTCONN; ++ } ++ ++ return t->send_pkt(reply); + } + + static void virtio_transport_wait_close(struct sock *sk, long timeout) diff --git a/queue-5.0/vxlan-fix-gro-cells-race-condition-between-receive-and-link-delete.patch b/queue-5.0/vxlan-fix-gro-cells-race-condition-between-receive-and-link-delete.patch new file mode 100644 index 00000000000..f409a1072d5 --- /dev/null +++ b/queue-5.0/vxlan-fix-gro-cells-race-condition-between-receive-and-link-delete.patch @@ -0,0 +1,53 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Stefano Brivio +Date: Fri, 8 Mar 2019 16:40:57 +0100 +Subject: vxlan: Fix GRO cells race condition between receive and link delete + +From: Stefano Brivio + +[ Upstream commit ad6c9986bcb627c7c22b8f9e9a934becc27df87c ] + +If we receive a packet while deleting a VXLAN device, there's a chance +vxlan_rcv() is called at the same time as vxlan_dellink(). This is fine, +except that vxlan_dellink() should never ever touch stuff that's still in +use, such as the GRO cells list. + +Otherwise, vxlan_rcv() crashes while queueing packets via +gro_cells_receive(). + +Move the gro_cells_destroy() to vxlan_uninit(), which runs after the RCU +grace period is elapsed and nothing needs the gro_cells anymore. + +This is now done in the same way as commit 8e816df87997 ("geneve: Use GRO +cells infrastructure.") originally implemented for GENEVE. + +Reported-by: Jianlin Shi +Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer") +Signed-off-by: Stefano Brivio +Reviewed-by: Sabrina Dubroca +Reviewed-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/vxlan.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/net/vxlan.c ++++ b/drivers/net/vxlan.c +@@ -2693,6 +2693,8 @@ static void vxlan_uninit(struct net_devi + { + struct vxlan_dev *vxlan = netdev_priv(dev); + ++ gro_cells_destroy(&vxlan->gro_cells); ++ + vxlan_fdb_delete_default(vxlan, vxlan->cfg.vni); + + free_percpu(dev->tstats); +@@ -3794,7 +3796,6 @@ static void vxlan_dellink(struct net_dev + + vxlan_flush(vxlan, true); + +- gro_cells_destroy(&vxlan->gro_cells); + list_del(&vxlan->next); + unregister_netdevice_queue(dev, head); + } diff --git a/queue-5.0/vxlan-test-dev-flags-iff_up-before-calling-gro_cells_receive.patch b/queue-5.0/vxlan-test-dev-flags-iff_up-before-calling-gro_cells_receive.patch new file mode 100644 index 00000000000..df47df58c0b --- /dev/null +++ b/queue-5.0/vxlan-test-dev-flags-iff_up-before-calling-gro_cells_receive.patch @@ -0,0 +1,67 @@ +From foo@baz Thu Mar 14 23:19:55 PDT 2019 +From: Eric Dumazet +Date: Sun, 10 Mar 2019 10:36:40 -0700 +Subject: vxlan: test dev->flags & IFF_UP before calling gro_cells_receive() + +From: Eric Dumazet + +[ Upstream commit 59cbf56fcd98ba2a715b6e97c4e43f773f956393 ] + +Same reasons than the ones explained in commit 4179cb5a4c92 +("vxlan: test dev->flags & IFF_UP before calling netif_rx()") + +netif_rx() or gro_cells_receive() must be called under a strict contract. + +At device dismantle phase, core networking clears IFF_UP +and flush_all_backlogs() is called after rcu grace period +to make sure no incoming packet might be in a cpu backlog +and still referencing the device. + +A similar protocol is used for gro_cells infrastructure, as +gro_cells_destroy() will be called only after a full rcu +grace period is observed after IFF_UP has been cleared. + +Most drivers call netif_rx() from their interrupt handler, +and since the interrupts are disabled at device dismantle, +netif_rx() does not have to check dev->flags & IFF_UP + +Virtual drivers do not have this guarantee, and must +therefore make the check themselves. + +Otherwise we risk use-after-free and/or crashes. + +Fixes: d342894c5d2f ("vxlan: virtual extensible lan") +Signed-off-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/vxlan.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/net/vxlan.c ++++ b/drivers/net/vxlan.c +@@ -1657,6 +1657,14 @@ static int vxlan_rcv(struct sock *sk, st + goto drop; + } + ++ rcu_read_lock(); ++ ++ if (unlikely(!(vxlan->dev->flags & IFF_UP))) { ++ rcu_read_unlock(); ++ atomic_long_inc(&vxlan->dev->rx_dropped); ++ goto drop; ++ } ++ + stats = this_cpu_ptr(vxlan->dev->tstats); + u64_stats_update_begin(&stats->syncp); + stats->rx_packets++; +@@ -1664,6 +1672,9 @@ static int vxlan_rcv(struct sock *sk, st + u64_stats_update_end(&stats->syncp); + + gro_cells_receive(&vxlan->gro_cells, skb); ++ ++ rcu_read_unlock(); ++ + return 0; + + drop: