commit 4eb9a81002485a7abfa53a334dde5bc10328079f Author: Greg Kroah-Hartman Date: Mon Nov 21 10:06:53 2016 +0100 Linux 4.4.34 commit b4bbdcef7d90ca44a1d1e0661eb009947134b20f Author: David S. Miller Date: Mon Oct 24 21:25:31 2016 -0700 sparc64: Delete now unused user copy fixup functions. [ Upstream commit 0fd0ff01d4c3c01e7fe69b762ee1a13236639acc ] Now that all of the user copy routines are converted to return accurate residual lengths when an exception occurs, we no longer need the broken fixup routines. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cb85910b0d450ddef15e4850b53bc56667b58ef3 Author: David S. Miller Date: Mon Oct 24 21:22:27 2016 -0700 sparc64: Delete now unused user copy assembler helpers. [ Upstream commit 614da3d9685b67917cab48c8452fd8bf93de0867 ] All of __ret{,l}_mone{_asi,_fp,_asi_fpu} are now unused. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1c7e17b1c4d60cc5aa575460f7efb73686dd3b39 Author: David S. Miller Date: Mon Oct 24 21:20:35 2016 -0700 sparc64: Convert U3copy_{from,to}_user to accurate exception reporting. [ Upstream commit ee841d0aff649164080e445e84885015958d8ff4 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7181969338f8b5f209f069e3db8d042325ff1b02 Author: David S. Miller Date: Mon Oct 24 20:46:44 2016 -0700 sparc64: Convert NG2copy_{from,to}_user to accurate exception reporting. [ Upstream commit e93704e4464fdc191f73fce35129c18de2ebf95d ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bfc8be6593097cb074d3912ba2f27565cfbb7d6e Author: David S. Miller Date: Mon Oct 24 19:32:12 2016 -0700 sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting. [ Upstream commit 7ae3aaf53f1695877ccd5ebbc49ea65991e41f1e ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dc3a7a7d2c85cb3162b46295ecb01ac78f3da1aa Author: David S. Miller Date: Mon Oct 24 18:58:05 2016 -0700 sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting. [ Upstream commit 95707704800988093a9b9a27e0f2f67f5b4bf2fa ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1731d90d8a558ecb20cdee0c2c001ae8e15c251d Author: David S. Miller Date: Mon Aug 15 16:07:50 2016 -0700 sparc64: Convert U1copy_{from,to}_user to accurate exception reporting. [ Upstream commit cb736fdbb208eb3420f1a2eb2bfc024a6e9dcada ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8a444c770f6ecb0fff7eb1d72ccbed9f82ced906 Author: David S. Miller Date: Mon Aug 15 15:26:38 2016 -0700 sparc64: Convert GENcopy_{from,to}_user to accurate exception reporting. [ Upstream commit d0796b555ba60c22eb41ae39a8362156cb08eee9 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c718e917b3d375bb016388861a20f169f4e8dce8 Author: David S. Miller Date: Mon Aug 15 15:08:18 2016 -0700 sparc64: Convert copy_in_user to accurate exception reporting. [ Upstream commit 0096ac9f47b1a2e851b3165d44065d18e5f13d58 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dd8a78b2b6ad24c7416dfe0443a31456cbad3b34 Author: David S. Miller Date: Mon Aug 15 14:47:54 2016 -0700 sparc64: Prepare to move to more saner user copy exception handling. [ Upstream commit 83a17d2661674d8c198adc0e183418f72aabab79 ] The fixup helper function mechanism for handling user copy fault handling is not %100 accurrate, and can never be made so. We are going to transition the code to return the running return return length, which is always kept track in one or more registers of each of these routines. In order to convert them one by one, we have to allow the existing behavior to continue functioning. Therefore make all the copy code that wants the fixup helper to be used return negative one. After all of the user copy routines have been converted, this logic and the fixup helpers themselves can be removed completely. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 756723ad553d02553397ea991c28812b91aa6cda Author: David S. Miller Date: Wed Aug 10 14:41:33 2016 -0700 sparc64: Delete __ret_efault. [ Upstream commit aa95ce361ed95c72ac42dcb315166bce5cf1a014 ] It is completely unused. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f5a69ff7486e473ea12288f5b729891ebde7fcfe Author: David S. Miller Date: Thu Oct 27 09:04:54 2016 -0700 sparc64: Handle extremely large kernel TLB range flushes more gracefully. [ Upstream commit a74ad5e660a9ee1d071665e7e8ad822784a2dc7f ] When the vmalloc area gets fragmented, and because the firmware mapping area sits between where modules live and the vmalloc area, we can sometimes receive requests for enormous kernel TLB range flushes. When this happens the cpu just spins flushing billions of pages and this triggers the NMI watchdog and other problems. We took care of this on the TSB side by doing a linear scan of the table once we pass a certain threshold. Do something similar for the TLB flush, however we are limited by the TLB flush facilities provided by the different chip variants. First of all we use an (mostly arbitrary) cut-off of 256K which is about 32 pages. This can be tuned in the future. The huge range code path for each chip works as follows: 1) On spitfire we flush all non-locked TLB entries using diagnostic acceses. 2) On cheetah we use the "flush all" TLB flush. 3) On sun4v/hypervisor we do a TLB context flush on context 0, which unlike previous chips does not remove "permanent" or locked entries. We could probably do something better on spitfire, such as limiting the flush to kernel TLB entries or even doing range comparisons. However that probably isn't worth it since those chips are old and the TLB only had 64 entries. Reported-by: James Clarke Tested-by: James Clarke Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d36a1ac49d243070cfbb76a594a44b334075b680 Author: David S. Miller Date: Wed Oct 26 10:20:14 2016 -0700 sparc64: Fix illegal relative branches in hypervisor patched TLB cross-call code. [ Upstream commit a236441bb69723032db94128761a469030c3fe6d ] Just like the non-cross-call TLB flush handlers, the cross-call ones need to avoid doing PC-relative branches outside of their code blocks. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5d8eb954763d972357037b34e98315b017b962d8 Author: David S. Miller Date: Wed Oct 26 10:08:22 2016 -0700 sparc64: Fix instruction count in comment for __hypervisor_flush_tlb_pending. [ Upstream commit 830cda3f9855ff092b0e9610346d110846fc497c ] Noticed by James Clarke. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 217f829ae96783d9b4968d941769fb4c15e380c6 Author: David S. Miller Date: Tue Oct 25 16:23:26 2016 -0700 sparc64: Fix illegal relative branches in hypervisor patched TLB code. [ Upstream commit b429ae4d5b565a71dfffd759dfcd4f6c093ced94 ] When we copy code over to patch another piece of code, we can only use PC-relative branches that target code within that piece of code. Such PC-relative branches cannot be made to external symbols because the patch moves the location of the code and thus modifies the relative address of external symbols. Use an absolute jmpl to fix this problem. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2ba06323db413dd0b8f501dfc32df5d55f17c520 Author: David S. Miller Date: Tue Oct 25 19:43:17 2016 -0700 sparc64: Handle extremely large kernel TSB range flushes sanely. [ Upstream commit 849c498766060a16aad5b0e0d03206726e7d2fa4 ] If the number of pages we are flushing is more than twice the number of entries in the TSB, just scan the TSB table for matches rather than probing each and every page in the range. Based upon a patch and report by James Clarke. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 75931800733c68082c530f6c5421928e4288ee9e Author: James Clarke Date: Mon Oct 24 19:49:25 2016 +0100 sparc: Handle negative offsets in arch_jump_label_transform [ Upstream commit 9d9fa230206a3aea6ef451646c97122f04777983 ] Additionally, if the offset will overflow the immediate for a ba,pt instruction, fall back on a standard ba to get an extra 3 bits. Signed-off-by: James Clarke Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8fd11efa2140192d1788302017368878ae6d357b Author: Mike Kravetz Date: Fri Jul 15 13:08:42 2016 -0700 sparc64 mm: Fix base TSB sizing when hugetlb pages are used [ Upstream commit af1b1a9b36b8f9d583d4b4f90dd8946ed0cd4bd0 ] do_sparc64_fault() calculates both the base and huge page RSS sizes and uses this information in calls to tsb_grow(). The calculation for base page TSB size is not correct if the task uses hugetlb pages. hugetlb pages are not accounted for in RSS, therefore the call to get_mm_rss(mm) does not include hugetlb pages. However, the number of pages based on huge_pte_count (which does include hugetlb pages) is subtracted from this value. This will result in an artificially small and often negative RSS calculation. The base TSB size is then often set to max_tsb_size as the passed RSS is unsigned, so a negative value looks really big. THP pages are also accounted for in huge_pte_count, and THP pages are accounted for in RSS so the calculation in do_sparc64_fault() is correct if a task only uses THP pages. A single huge_pte_count is not sufficient for TSB sizing if both hugetlb and THP pages can be used. Instead of a single counter, use two: one for hugetlb and one for THP. Signed-off-by: Mike Kravetz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e90b688013526340fef9f11ae0184888fd563d1 Author: Dan Carpenter Date: Fri Jul 15 14:17:33 2016 +0300 sparc: serial: sunhv: fix a double lock bug [ Upstream commit 344e3c7734d5090b148c19ac6539b8947fed6767 ] We accidentally take the "port->lock" twice in a row. This old code was supposed to be deleted. Fixes: e58e241c1788 ('sparc: serial: Clean up the locking for -rt') Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a395f7a66eec5db41f8860427f955d4cdabb1063 Author: David S. Miller Date: Wed Jul 27 17:50:26 2016 -0700 sparc: Don't leak context bits into thread->fault_address [ Upstream commit 4f6deb8cbab532a8d7250bc09234c1795ecb5e2c ] On pre-Niagara systems, we fetch the fault address on data TLB exceptions from the TLB_TAG_ACCESS register. But this register also contains the context ID assosciated with the fault in the low 13 bits of the register value. This propagates into current_thread_info()->fault_address and can cause trouble later on. So clear the low 13-bits out of the TLB_TAG_ACCESS value in the cases where it matters. Reported-by: Mikulas Patocka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e772c53ab9836b083c21acf9d2d76805e1d133e Author: Peter Hurley Date: Fri Nov 27 14:30:21 2015 -0500 tty: Prevent ldisc drivers from re-using stale tty fields commit dd42bf1197144ede075a9d4793123f7689e164bc upstream. Line discipline drivers may mistakenly misuse ldisc-related fields when initializing. For example, a failure to initialize tty->receive_room in the N_GIGASET_M101 line discipline was recently found and fixed [1]. Now, the N_X25 line discipline has been discovered accessing the previous line discipline's already-freed private data [2]. Harden the ldisc interface against misuse by initializing revelant tty fields before instancing the new line discipline. [1] commit fd98e9419d8d622a4de91f76b306af6aa627aa9c Author: Tilman Schmidt Date: Tue Jul 14 00:37:13 2015 +0200 isdn/gigaset: reset tty->receive_room when attaching ser_gigaset [2] Report from Sasha Levin [ 634.336761] ================================================================== [ 634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0 [ 634.339558] Read of size 4 by task syzkaller_execu/8981 [ 634.340359] ============================================================================= [ 634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected ... [ 634.405018] Call Trace: [ 634.405277] dump_stack (lib/dump_stack.c:52) [ 634.405775] print_trailer (mm/slub.c:655) [ 634.406361] object_err (mm/slub.c:662) [ 634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236) [ 634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279) [ 634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1)) [ 634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447) [ 634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567) [ 634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879) [ 634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607) [ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613) [ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188) Cc: Tilman Schmidt Cc: Sasha Levin Signed-off-by: Peter Hurley Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 225a24ae97331f3b9d97c1bb97b1e30b3633bcf4 Author: Eric Dumazet Date: Thu Nov 10 13:12:35 2016 -0800 tcp: take care of truncations done by sk_filter() [ Upstream commit ac6e780070e30e4c35bd395acfe9191e6268bdd3 ] With syzkaller help, Marco Grassi found a bug in TCP stack, crashing in tcp_collapse() Root cause is that sk_filter() can truncate the incoming skb, but TCP stack was not really expecting this to happen. It probably was expecting a simple DROP or ACCEPT behavior. We first need to make sure no part of TCP header could be removed. Then we need to adjust TCP_SKB_CB(skb)->end_seq Many thanks to syzkaller team and Marco for giving us a reproducer. Signed-off-by: Eric Dumazet Reported-by: Marco Grassi Reported-by: Vladis Dronov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ae9e052a58ef2357e4b7543901af8f6daf91a0f7 Author: Stephen Suryaputra Lin Date: Thu Nov 10 11:16:15 2016 -0500 ipv4: use new_gw for redirect neigh lookup [ Upstream commit 969447f226b451c453ddc83cac6144eaeac6f2e3 ] In v2.6, ip_rt_redirect() calls arp_bind_neighbour() which returns 0 and then the state of the neigh for the new_gw is checked. If the state isn't valid then the redirected route is deleted. This behavior is maintained up to v3.5.7 by check_peer_redirect() because rt->rt_gateway is assigned to peer->redirect_learned.a4 before calling ipv4_neigh_lookup(). After commit 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again."), ipv4_neigh_lookup() is performed without the rt_gateway assigned to the new_gw. In the case when rt_gateway (old_gw) isn't zero, the function uses it as the key. The neigh is most likely valid since the old_gw is the one that sends the ICMP redirect message. Then the new_gw is assigned to fib_nh_exception. The problem is: the new_gw ARP may never gets resolved and the traffic is blackholed. So, use the new_gw for neigh lookup. Changes from v1: - use __ipv4_neigh_lookup instead (per Eric Dumazet). Fixes: 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again.") Signed-off-by: Stephen Suryaputra Lin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5c67f9477bb2122a84ad99f6e6d492bebbdf549b Author: Eric Dumazet Date: Wed Nov 9 16:04:46 2016 -0800 net: __skb_flow_dissect() must cap its return value [ Upstream commit 34fad54c2537f7c99d07375e50cb30aa3c23bd83 ] After Tom patch, thoff field could point past the end of the buffer, this could fool some callers. If an skb was provided, skb->len should be the upper limit. If not, hlen is supposed to be the upper limit. Fixes: a6e544b0a88b ("flow_dissector: Jump to exit code in __skb_flow_dissect") Signed-off-by: Eric Dumazet Reported-by: Yibin Yang Acked-by: Willem de Bruijn Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b67ed647d135d0c0fbb3165d3c7b8c4bd68fe7be Author: Soheil Hassas Yeganeh Date: Fri Nov 4 15:36:49 2016 -0400 sock: fix sendmmsg for partial sendmsg [ Upstream commit 3023898b7d4aac65987bd2f485cc22390aae6f78 ] Do not send the next message in sendmmsg for partial sendmsg invocations. sendmmsg assumes that it can continue sending the next message when the return value of the individual sendmsg invocations is positive. It results in corrupting the data for TCP, SCTP, and UNIX streams. For example, sendmmsg([["abcd"], ["efgh"]]) can result in a stream of "aefgh" if the first sendmsg invocation sends only the first byte while the second sendmsg goes through. Datagram sockets either send the entire datagram or fail, so this patch affects only sockets of type SOCK_STREAM and SOCK_SEQPACKET. Fixes: 228e548e6020 ("net: Add sendmmsg socket system call") Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: Eric Dumazet Signed-off-by: Willem de Bruijn Signed-off-by: Neal Cardwell Acked-by: Maciej Żenczykowski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0650eeb4f187c4f680f628fac03db55441272154 Author: Alexander Duyck Date: Fri Nov 4 15:11:57 2016 -0400 fib_trie: Correct /proc/net/route off by one error [ Upstream commit fd0285a39b1cb496f60210a9a00ad33a815603e7 ] The display of /proc/net/route has had a couple issues due to the fact that when I originally rewrote most of fib_trie I made it so that the iterator was tracking the next value to use instead of the current. In addition it had an off by 1 error where I was tracking the first piece of data as position 0, even though in reality that belonged to the SEQ_START_TOKEN. This patch updates the code so the iterator tracks the last reported position and key instead of the next expected position and key. In addition it shifts things so that all of the leaves start at 1 instead of trying to report leaves starting with offset 0 as being valid. With these two issues addressed this should resolve any off by one errors that were present in the display of /proc/net/route. Fixes: 25b97c016b26 ("ipv4: off-by-one in continuation handling in /proc/net/route") Cc: Andy Whitcroft Reported-by: Jason Baron Tested-by: Jason Baron Signed-off-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f8857a4971d69af7caf415e05a6bb415fe800d4 Author: Marcelo Ricardo Leitner Date: Thu Nov 3 17:03:41 2016 -0200 sctp: assign assoc_id earlier in __sctp_connect [ Upstream commit 7233bc84a3aeda835d334499dc00448373caf5c0 ] sctp_wait_for_connect() currently already holds the asoc to keep it alive during the sleep, in case another thread release it. But Andrey Konovalov and Dmitry Vyukov reported an use-after-free in such situation. Problem is that __sctp_connect() doesn't get a ref on the asoc and will do a read on the asoc after calling sctp_wait_for_connect(), but by then another thread may have closed it and the _put on sctp_wait_for_connect will actually release it, causing the use-after-free. Fix is, instead of doing the read after waiting for the connect, do it before so, and avoid this issue as the socket is still locked by then. There should be no issue on returning the asoc id in case of failure as the application shouldn't trust on that number in such situations anyway. This issue doesn't exist in sctp_sendmsg() path. Reported-by: Dmitry Vyukov Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Marcelo Ricardo Leitner Reviewed-by: Xin Long Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 65d29c185614806fafa281e0902dc3b61fd9e37a Author: Eric Dumazet Date: Thu Nov 3 08:59:46 2016 -0700 ipv6: dccp: add missing bind_conflict to dccp_ipv6_mapped [ Upstream commit 990ff4d84408fc55942ca6644f67e361737b3d8e ] While fuzzing kernel with syzkaller, Andrey reported a nasty crash in inet6_bind() caused by DCCP lacking a required method. Fixes: ab1e0a13d7029 ("[SOCK] proto: Add hashinfo member to struct proto") Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Cc: Arnaldo Carvalho de Melo Acked-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 99131760a8851e6e5b2c9b24d0a68a3068923a08 Author: Eric Dumazet Date: Wed Nov 2 20:30:48 2016 -0700 ipv6: dccp: fix out of bound access in dccp_v6_err() [ Upstream commit 1aa9d1a0e7eefcc61696e147d123453fc0016005 ] dccp_v6_err() does not use pskb_may_pull() and might access garbage. We only need 4 bytes at the beginning of the DCCP header, like TCP, so the 8 bytes pulled in icmpv6_notify() are more than enough. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a2df29ed840f90e459a3f8ff029b216be3912731 Author: Eric Dumazet Date: Wed Nov 2 19:00:40 2016 -0700 dccp: fix out of bound access in dccp_v4_err() [ Upstream commit 6706a97fec963d6cb3f7fc2978ec1427b4651214 ] dccp_v4_err() does not use pskb_may_pull() and might access garbage. We only need 4 bytes at the beginning of the DCCP header, like TCP, so the 8 bytes pulled in icmp_socket_deliver() are more than enough. This patch might allow to process more ICMP messages, as some routers are still limiting the size of reflected bytes to 28 (RFC 792), instead of extended lengths (RFC 1812 4.3.2.3) Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ad6d0a82016bc1920725f23d5d86b7518dd5f999 Author: Eric Dumazet Date: Wed Nov 2 18:04:24 2016 -0700 dccp: do not send reset to already closed sockets [ Upstream commit 346da62cc186c4b4b1ac59f87f4482b47a047388 ] Andrey reported following warning while fuzzing with syzkaller WARNING: CPU: 1 PID: 21072 at net/dccp/proto.c:83 dccp_set_state+0x229/0x290 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 21072 Comm: syz-executor Not tainted 4.9.0-rc1+ #293 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff88003d4c7738 ffffffff81b474f4 0000000000000003 dffffc0000000000 ffffffff844f8b00 ffff88003d4c7804 ffff88003d4c7800 ffffffff8140c06a 0000000041b58ab3 ffffffff8479ab7d ffffffff8140beae ffffffff8140cd00 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0xb3/0x10f lib/dump_stack.c:51 [] panic+0x1bc/0x39d kernel/panic.c:179 [] __warn+0x1cc/0x1f0 kernel/panic.c:542 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585 [] dccp_set_state+0x229/0x290 net/dccp/proto.c:83 [] dccp_close+0x612/0xc10 net/dccp/proto.c:1016 [] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415 [] sock_release+0x8e/0x1d0 net/socket.c:570 [] sock_close+0x16/0x20 net/socket.c:1017 [] __fput+0x29d/0x720 fs/file_table.c:208 [] ____fput+0x15/0x20 fs/file_table.c:244 [] task_work_run+0xf8/0x170 kernel/task_work.c:116 [< inline >] exit_task_work include/linux/task_work.h:21 [] do_exit+0x883/0x2ac0 kernel/exit.c:828 [] do_group_exit+0x10e/0x340 kernel/exit.c:931 [] get_signal+0x634/0x15a0 kernel/signal.c:2307 [] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807 [] exit_to_usermode_loop+0xe5/0x130 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [] syscall_return_slowpath+0x1a8/0x1e0 arch/x86/entry/common.c:259 [] entry_SYSCALL_64_fastpath+0xc0/0xc2 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Fix this the same way we did for TCP in commit 565b7b2d2e63 ("tcp: do not send reset to already closed sockets") Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 69a5c7ca2e62072bcf2de664fdf038b64133d5d5 Author: Eric Dumazet Date: Wed Nov 2 07:53:17 2016 -0700 tcp: fix potential memory corruption [ Upstream commit ac9e70b17ecd7c6e933ff2eaf7ab37429e71bf4d ] Imagine initial value of max_skb_frags is 17, and last skb in write queue has 15 frags. Then max_skb_frags is lowered to 14 or smaller value. tcp_sendmsg() will then be allowed to add additional page frags and eventually go past MAX_SKB_FRAGS, overflowing struct skb_shared_info. Fixes: 5f74f82ea34c ("net:Add sysctl_max_skb_frags") Signed-off-by: Eric Dumazet Cc: Hans Westgaard Ry Cc: Håkon Bugge Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8777977b22c47c47873bdf9e88aa20cc701257bd Author: Eli Cooper Date: Tue Nov 1 23:45:12 2016 +0800 ip6_tunnel: Clear IP6CB in ip6tunnel_xmit() [ Upstream commit 23f4ffedb7d751c7e298732ba91ca75d224bc1a6 ] skb->cb may contain data from previous layers. In the observed scenario, the garbage data were misinterpreted as IP6CB(skb)->frag_max_size, so that small packets sent through the tunnel are mistakenly fragmented. This patch unconditionally clears the control buffer in ip6tunnel_xmit(), which affects ip6_tunnel, ip6_udp_tunnel and ip6_gre. Currently none of these tunnels set IP6CB(skb)->flags, otherwise it needs to be done earlier. Cc: stable@vger.kernel.org Signed-off-by: Eli Cooper Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c5bad811ca4d4bb5ad1fc44bed4f77efd831878e Author: Andy Gospodarek Date: Mon Oct 31 13:32:03 2016 -0400 bgmac: stop clearing DMA receive control register right after it is set [ Upstream commit fcdefccac976ee51dd6071832b842d8fb41c479c ] Current bgmac code initializes some DMA settings in the receive control register for some hardware and then immediately clears those settings. Not clearing those settings results in ~420Mbps *improvement* in throughput; this system can now receive frames at line-rate on Broadcom 5871x hardware compared to ~520Mbps today. I also tested a few other values but found there to be no discernible difference in CPU utilization even if burst size and prefetching values are different. On the hardware tested there was no need to keep the code that cleared all but bits 16-17, but since there is a wide variety of hardware that used this driver (I did not look at all hardware docs for hardware using this IP block), I find it wise to move this call up and clear bits just after reading the default value from the hardware rather than completely removing it. This is a good candidate for -stable >=3.14 since that is when the code that was supposed to improve performance (but did not) was introduced. Signed-off-by: Andy Gospodarek Fixes: 56ceecde1f29 ("bgmac: initialize the DMA controller of core...") Cc: Hauke Mehrtens Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6e9ca1b61cc8a129254fe0b50d21fba7404529c0 Author: Eric Dumazet Date: Sat Oct 29 11:02:36 2016 -0700 net: mangle zero checksum in skb_checksum_help() [ Upstream commit 4f2e4ad56a65f3b7d64c258e373cb71e8d2499f4 ] Sending zero checksum is ok for TCP, but not for UDP. UDPv6 receiver should by default drop a frame with a 0 checksum, and UDPv4 would not verify the checksum and might accept a corrupted packet. Simply replace such checksum by 0xffff, regardless of transport. This error was caught on SIT tunnels, but seems generic. Signed-off-by: Eric Dumazet Cc: Maciej Żenczykowski Cc: Willem de Bruijn Acked-by: Maciej Żenczykowski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ac4c2cf6f57a399213478495dbf3315c01c797ab Author: Eric Dumazet Date: Fri Oct 28 13:40:24 2016 -0700 net: clear sk_err_soft in sk_clone_lock() [ Upstream commit e551c32d57c88923f99f8f010e89ca7ed0735e83 ] At accept() time, it is possible the parent has a non zero sk_err_soft, leftover from a prior error. Make sure we do not leave this value in the child, as it makes future getsockopt(SO_ERROR) calls quite unreliable. Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 74e53a3a053fc6dd6fc83b4dc4cda2524931b3e3 Author: Florian Westphal Date: Fri Oct 28 18:43:11 2016 +0200 dctcp: avoid bogus doubling of cwnd after loss [ Upstream commit ce6dd23329b1ee6a794acf5f7e40f8e89b8317ee ] If a congestion control module doesn't provide .undo_cwnd function, tcp_undo_cwnd_reduction() will set cwnd to tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh << 1); ... which makes sense for reno (it sets ssthresh to half the current cwnd), but it makes no sense for dctcp, which sets ssthresh based on the current congestion estimate. This can cause severe growth of cwnd (eventually overflowing u32). Fix this by saving last cwnd on loss and restore cwnd based on that, similar to cubic and other algorithms. Fixes: e3118e8359bb7c ("net: tcp: add DCTCP congestion control algorithm") Cc: Lawrence Brakmo Cc: Andrew Shewmaker Cc: Glenn Judd Acked-by: Daniel Borkmann Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman