commit 6733ad64746e249e149efd8c01a342bcd51a906d Author: Jiri Slaby Date: Mon Mar 6 10:10:22 2017 +0100 Linux 3.12.71 commit e6b7fdc02b3beaa6d583b9fbb212f516fe1905f8 Author: Johan Hovold Date: Mon May 26 19:23:43 2014 +0200 USB: cdc-acm: fix failed open not being detected commit 8727bf689a77a79816065e23a7a58a474ad544f9 upstream. Fix errors during open not being returned to userspace. Specifically, failed control-line manipulations or control or read urb submissions would not be detected. Fixes: 7fb57a019f94 ("USB: cdc-acm: Fix potential deadlock (lockdep warning)") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 0bb6506d9bd0ab62b05335b569be1f5fff556229 Author: Johan Hovold Date: Mon May 26 19:23:42 2014 +0200 USB: cdc-acm: fix open and suspend race commit 703df3297fb1950b0aa53e656108eb936d3f21d9 upstream. We must not do the usb_autopm_put_interface() before submitting the read urbs or we might end up doing I/O to a suspended device. Fixes: 088c64f81284 ("USB: cdc-acm: re-write read processing") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit bdd76f4593d8df975b31407a37ea2495b29b5d58 Author: Alexey Khoroshilov Date: Sat Apr 12 02:10:45 2014 +0400 USB: cdc-acm: fix double usb_autopm_put_interface() in acm_port_activate() commit 070c0b17f6a1ba39dff9be112218127e7e8fd456 upstream. If acm_submit_read_urbs() fails in acm_port_activate(), error handling code calls usb_autopm_put_interface() while it is already called before acm_submit_read_urbs(). The patch reorganizes error handling code to avoid double decrement of USB interface's PM-usage counter. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 5cb402ee650ef264d02b0ce303886408ad33dad8 Author: Heiko Carstens Date: Wed May 14 09:48:21 2014 +0200 net: filter: s390: fix JIT address randomization commit e84d2f8d2ae33c8215429824e1ecf24cbca9645e upstream. This is the s390 variant of Alexei's JIT bug fix. (patch description below stolen from Alexei's patch) bpf_alloc_binary() adds 128 bytes of room to JITed program image and rounds it up to the nearest page size. If image size is close to page size (like 4000), it is rounded to two pages: round_up(4000 + 4 + 128) == 8192 then 'hole' is computed as 8192 - (4000 + 4) = 4188 If prandom_u32() % hole selects a number >= PAGE_SIZE - sizeof(*header) then kernel will crash during bpf_jit_free(): kernel BUG at arch/x86/mm/pageattr.c:887! Call Trace: [] change_page_attr_set_clr+0x135/0x460 [] ? _raw_spin_unlock_irq+0x30/0x50 [] set_memory_rw+0x2f/0x40 [] bpf_jit_free_deferred+0x2d/0x60 [] process_one_work+0x1d8/0x6a0 [] ? process_one_work+0x178/0x6a0 [] worker_thread+0x11c/0x370 since bpf_jit_free() does: unsigned long addr = (unsigned long)fp->bpf_func & PAGE_MASK; struct bpf_binary_header *header = (void *)addr; to compute start address of 'bpf_binary_header' and header->pages will pass junk to: set_memory_rw(addr, header->pages); Fix it by making sure that &header->image[prandom_u32() % hole] and &header are in the same page. Fixes: aa2d2c73c21f2 ("s390/bpf,jit: address randomize and write protect jit code") Reported-by: Alexei Starovoitov Signed-off-by: Heiko Carstens Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit ba6f34feca6ff27b35d777c9bdbc2d0c9cf29303 Author: Alexei Starovoitov Date: Tue May 13 15:05:55 2014 -0700 net: filter: x86: fix JIT address randomization commit 773cd38f40b8834be991dbfed36683acc1dd41ee upstream. bpf_alloc_binary() adds 128 bytes of room to JITed program image and rounds it up to the nearest page size. If image size is close to page size (like 4000), it is rounded to two pages: round_up(4000 + 4 + 128) == 8192 then 'hole' is computed as 8192 - (4000 + 4) = 4188 If prandom_u32() % hole selects a number >= PAGE_SIZE - sizeof(*header) then kernel will crash during bpf_jit_free(): kernel BUG at arch/x86/mm/pageattr.c:887! Call Trace: [] change_page_attr_set_clr+0x135/0x460 [] ? _raw_spin_unlock_irq+0x30/0x50 [] set_memory_rw+0x2f/0x40 [] bpf_jit_free_deferred+0x2d/0x60 [] process_one_work+0x1d8/0x6a0 [] ? process_one_work+0x178/0x6a0 [] worker_thread+0x11c/0x370 since bpf_jit_free() does: unsigned long addr = (unsigned long)fp->bpf_func & PAGE_MASK; struct bpf_binary_header *header = (void *)addr; to compute start address of 'bpf_binary_header' and header->pages will pass junk to: set_memory_rw(addr, header->pages); Fix it by making sure that &header->image[prandom_u32() % hole] and &header are in the same page Fixes: 314beb9bcabfd ("x86: bpf_jit_comp: secure bpf jit against spraying attacks") Signed-off-by: Alexei Starovoitov Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit b24cd48cfb7dd16759feb6e6e5f1b0533ed6ae2b Author: Claudiu Manoil Date: Wed Apr 23 16:38:47 2014 +0300 gianfar: Check if phydev present on ethtool -A commit 98a46d46d1bc983125b6ff9a0e831050a7011713 upstream. This fixes a seg fault on 'ethtool -A' entry if the interface is down. Obviously we need to have the phy device initialized / "connected" (see of_phy_connect()) to be able to advertise pause frame capabilities. Fixes: 23402bddf9e56eecb27bbd1e5467b3b79b3dbe58 Signed-off-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 42e99f1ca072b4e1c0ea6682d7c2c63929f3f3e2 Author: Thomas Petazzoni Date: Fri Apr 18 14:19:53 2014 +0200 PCI: mvebu: split PCIe BARs into multiple MBus windows when needed commit 398f5d5e10b6b917cd9d35ef21d545b0afbada22 upstream. MBus windows are used on Marvell platforms to map certain peripherals in the physical address space. In the PCIe context, MBus windows are needed to map PCIe I/O and memory regions in the physical address. However, those MBus windows can only have power of two sizes, while PCIe BAR do not necessarily guarantee this. For this reason, the current pci-mvebu breaks on platforms where PCIe devices have BARs that don't sum up to a power of two size at the emulated bridge level. This commit fixes this by allowing the pci-mvebu driver to create multiple contiguous MBus windows (each having a power of two size) to cover a given PCIe BAR. To achieve this, two functions are added: mvebu_pcie_add_windows() and mvebu_pcie_del_windows() to respectively add and remove all the MBus windows that are needed to map the provided PCIe region base and size. The emulated PCI bridge code now calls those functions, instead of directly calling the mvebu-mbus driver functions. Fixes: 45361a4fe446 ('pci: PCIe driver for Marvell Armada 370/XP systems') Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397823593-1932-8-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex Acked-by: Bjorn Helgaas Signed-off-by: Jason Cooper Signed-off-by: Jiri Slaby commit 9921463b3aef9307dc9e19b1d6632b8d00f5bad2 Author: Jingoo Han Date: Fri Dec 27 09:34:36 2013 +0900 PCI: mvebu: Use max_t() instead of max(resource_size_t,) commit 06489002a175680e18b4c0dd0beb6aff2a6d3781 upstream. Use max_t() instead of max(resource_size_t,) in order to fix the following checkpatch warning. WARNING: max() should probably be max_t(resource_size_t, SZ_64K, size) WARNING: max() should probably be max_t(resource_size_t, SZ_1M, size) Signed-off-by: Jingoo Han Signed-off-by: Bjorn Helgaas Acked-by: Jason Cooper Signed-off-by: Jiri Slaby commit ca5fbde47e1e6cb4abdd1b5a20385022f8103a56 Author: Steffen Klassert Date: Wed Apr 16 09:01:03 2014 +0200 vti4: Don't count header length twice. commit a32452366b7250c42e96a18ffc3ad8db9e0ca3c2 upstream. We currently count the size of LL_MAX_HEADER and struct iphdr twice for vti4 devices, this leads to a wrong device mtu. The size of LL_MAX_HEADER and struct iphdr is already counted in ip_tunnel_bind_dev(), so don't do it again in vti_tunnel_init(). Fixes: b9959fd3 ("vti: switch to new ip tunnel code") Signed-off-by: Steffen Klassert Signed-off-by: Jiri Slaby commit d2c2bdcdd8c5ce3d2a68aa3353ed1f340c3e500e Author: Daniel Borkmann Date: Thu Feb 20 20:51:06 2014 +0100 net: sctp: rework multihoming retransmission path selection to rfc4960 commit 4c47af4d5eb2c2f78f886079a3920a7078a6f0a0 upstream. Problem statement: 1) both paths (primary path1 and alternate path2) are up after the association has been established i.e., HB packets are normally exchanged, 2) path2 gets inactive after path_max_retrans * max_rto timed out (i.e. path2 is down completely), 3) now, if a transmission times out on the only surviving/active path1 (any ~1sec network service impact could cause this like a channel bonding failover), then the retransmitted packets are sent over the inactive path2; this happens with partial failover and without it. Besides not being optimal in the above scenario, a small failure or timeout in the only existing path has the potential to cause long delays in the retransmission (depending on RTO_MAX) until the still active path is reselected. Further, when the T3-timeout occurs, we have active_patch == retrans_path, and even though the timeout occurred on the initial transmission of data, not a retransmit, we end up updating retransmit path. RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under 6.4.1. "Failover from an Inactive Destination Address" the following: Some of the transport addresses of a multi-homed SCTP endpoint may become inactive due to either the occurrence of certain error conditions (see Section 8.2) or adjustments from the SCTP user. When there is outbound data to send and the primary path becomes inactive (e.g., due to failures), or where the SCTP user explicitly requests to send data to an inactive destination transport address, before reporting an error to its ULP, the SCTP endpoint should try to send the data to an alternate __active__ destination transport address if one exists. When retransmitting data that timed out, if the endpoint is multihomed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting timed-out data, the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted. Note: Rules for picking the most divergent source-destination pair are an implementation decision and are not specified within this document. So, we should first reconsider to take the current active retransmission transport if we cannot find an alternative active one. If all of that fails, we can still round robin through unkown, partial failover, and inactive ones in the hope to find something still suitable. Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke that behaviour by selecting the next inactive transport when no other active transport was found besides the current assoc's peer.retran_path. Before commit 4141ddc02a92, we would have traversed through the list until we reach our peer.retran_path again, and in case that is still in state SCTP_ACTIVE, we would take it and return. Only if that is not the case either, we take the next inactive transport. Besides all that, another issue is that transports in state SCTP_UNKNOWN could be preferred over transports in state SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after SCTP_UNKNOWN in the transport list yielding a weaker transport state to be used in retransmission. This patch mostly reverts 4141ddc02a92, but also rewrites this function to introduce more clarity and strictness into the code. A strict priority of transport states is enforced in this patch, hence selection is active > unkown > partial failover > inactive. Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix") Signed-off-by: Daniel Borkmann Cc: Gui Jianfeng Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6a4840575c9c7c43ee10ba105ccdbd77f9501a6e Author: Hannes Frederic Sowa Date: Thu Jan 16 20:13:04 2014 +0100 ipv6: simplify detection of first operational link-local address on interface commit 11ffff752c6a5adc86f7dd397b2f75af8f917c51 upstream. In commit 1ec047eb4751e3 ("ipv6: introduce per-interface counter for dad-completed ipv6 addresses") I build the detection of the first operational link-local address much to complex. Additionally this code now has a race condition. Replace it with a much simpler variant, which just scans the address list when duplicate address detection completes, to check if this is the first valid link local address and send RS and MLD reports then. Fixes: 1ec047eb4751e3 ("ipv6: introduce per-interface counter for dad-completed ipv6 addresses") Reported-by: Jiri Pirko Cc: Flavio Leitner Signed-off-by: Hannes Frederic Sowa Acked-by: Flavio Leitner Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit d6ec2447c0a8582b947becf448edb7cb70ca7031 Author: Daniel Borkmann Date: Mon Jan 6 01:45:50 2014 +0100 net: 6lowpan: fix lowpan_header_create non-compression memcpy call commit 965801e1eb624154fe5e9dc5d2ff0b7f1951a11c upstream. In function lowpan_header_create(), we invoke the following code construct: struct ipv6hdr *hdr; ... hdr = ipv6_hdr(skb); ... if (...) memcpy(hc06_ptr + 1, &hdr->flow_lbl[1], 2); else memcpy(hc06_ptr, &hdr, 4); Where the else path of the condition, that is, non-compression path, calls memcpy() with a pointer to struct ipv6hdr *hdr as source, thus two levels of indirection. This cannot be correct, and likely only one level of pointer was intended as source buffer for memcpy() here. Fixes: 44331fe2aa0d ("IEEE802.15.4: 6LoWPAN basic support") Signed-off-by: Daniel Borkmann Cc: Alexander Smirnov Cc: Dmitry Eremin-Solenikov Cc: Werner Almesberger Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6da68047088296c48bf2a2583152335726c74272 Author: Li RongQing Date: Thu Jan 2 13:20:12 2014 +0800 ipv6: fix the use of pcpu_tstats in ip6_tunnel commit abb6013cca147ad940b0e9fee260d2d9e93b7018 upstream. when read/write the 64bit data, the correct lock should be hold. Fixes: 87b6d218f3adb ("tunnel: implement 64 bits statistics") Cc: Stephen Hemminger Cc: Eric Dumazet Signed-off-by: Li RongQing Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit d66961bfd950db50ec7278430357a78afb7f14f4 Author: Viresh Kumar Date: Tue Dec 24 07:11:01 2013 +0530 cpufreq: preserve user_policy across suspend/resume commit 08fd8c1cf0a99abf34e09a8b99b74872e0d73a23 upstream. Prevent __cpufreq_add_dev() from overwriting the existing values of user_policy.{min|max|policy|governor} with defaults during resume from system suspend. Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume") Reported-by: Bjørn Mork Signed-off-by: Viresh Kumar [rjw: Changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit d00f85b22a4bfa1db18088216ae130cd00d86b57 Author: Rafael J. Wysocki Date: Fri Dec 27 01:07:11 2013 +0100 cpufreq: Clean up after a failing light-weight initialization commit 72368d122c7479aa6e14fbbd334717b8a0c157a6 upstream. If cpufreq_policy_restore() returns NULL during system resume, __cpufreq_add_dev() should just fall back to the full initialization instead of returning an error, because that may actually make things work. Moreover, it should not leave stale fallback data behind after it has failed to restore a previously existing policy. This change is based on Viresh Kumar's work. Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume") Reported-by: Bjørn Mork Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Signed-off-by: Jiri Slaby commit 83b8aa4c54c1cd83648e9f8f6039ed20b954baaa Author: Viresh Kumar Date: Fri Dec 20 21:26:02 2013 +0530 cpufreq: remove sysfs files for CPUs which failed to come back after resume commit 42f921a6f10c6c2079b093a115eb7e3c3508357f upstream. There are cases where cpufreq_add_dev() may fail for some CPUs during system resume. With the current code we will still have sysfs cpufreq files for those CPUs and struct cpufreq_policy would be already freed for them. Hence any operation on those sysfs files would result in kernel warnings. Example of problems resulting from resume errors (from Bjørn Mork): WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212() missing sysfs attribute operations for kobject: (null) Modules linked in: [stripped as irrelevant] CPU: 0 PID: 6055 Comm: grep Tainted: G D 3.13.0-rc2 #153 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006 ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000 ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310 Call Trace: [] dump_stack+0x55/0x76 [] warn_slowpath_common+0x7c/0x96 [] ? sysfs_open_file+0x77/0x212 [] warn_slowpath_fmt+0x41/0x43 [] ? sysfs_get_active+0x6b/0x82 [] ? sysfs_open_file+0x32/0x212 [] sysfs_open_file+0x77/0x212 [] ? sysfs_schedule_callback+0x1ac/0x1ac [] do_dentry_open+0x17c/0x257 [] finish_open+0x41/0x4f [] do_last+0x80c/0x9ba [] ? inode_permission+0x40/0x42 [] path_openat+0x233/0x4a1 [] do_filp_open+0x35/0x85 [] ? __alloc_fd+0x172/0x184 [] do_sys_open+0x6b/0xfa [] SyS_openat+0xf/0x11 [] system_call_fastpath+0x16/0x1b To fix this, remove those sysfs files or put the associated kobject in case of such errors. Also, to make it simple, remove the cpufreq sysfs links from all the CPUs (except for the policy->cpu) during suspend, as that operation won't result in a loss of sysfs file permissions and we can create those links during resume just fine. [js] no rwsem in 3.12 yet Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume") Reported-and-tested-by: Bjørn Mork Signed-off-by: Viresh Kumar [rjw: Changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 85acaced614b6921756df9fc4aa5e9b014fa04cf Author: Bjørn Mork Date: Tue Dec 3 12:14:32 2013 +0100 cpufreq: fix garbage kobjects on errors during suspend/resume commit 2167e2399dc5e69c62db56d933e9c8cbe107620a upstream. This is effectively a revert of commit 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume"), which enabled suspend/resume optimizations leaving the sysfs files in place. Errors during suspend/resume are not handled properly, leaving dead sysfs attributes in case of failures. There are are number of functions with special code for the "frozen" case, and all these need to also have special error handling. The problem is easy to demonstrate by making cpufreq_driver->init() or cpufreq_driver->get() fail during resume. The code is too complex for a simple fix, with split code paths in multiple blocks within a number of functions. It is therefore best to revert the patch enabling this code until the error handling is in place. Examples of problems resulting from resume errors: WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212() missing sysfs attribute operations for kobject: (null) Modules linked in: [stripped as irrelevant] CPU: 0 PID: 6055 Comm: grep Tainted: G D 3.13.0-rc2 #153 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006 ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000 ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310 Call Trace: [] dump_stack+0x55/0x76 [] warn_slowpath_common+0x7c/0x96 [] ? sysfs_open_file+0x77/0x212 [] warn_slowpath_fmt+0x41/0x43 [] ? sysfs_get_active+0x6b/0x82 [] ? sysfs_open_file+0x32/0x212 [] sysfs_open_file+0x77/0x212 [] ? sysfs_schedule_callback+0x1ac/0x1ac [] do_dentry_open+0x17c/0x257 [] finish_open+0x41/0x4f [] do_last+0x80c/0x9ba [] ? inode_permission+0x40/0x42 [] path_openat+0x233/0x4a1 [] do_filp_open+0x35/0x85 [] ? __alloc_fd+0x172/0x184 [] do_sys_open+0x6b/0xfa [] SyS_openat+0xf/0x11 [] system_call_fastpath+0x16/0x1b The failure to restore cpufreq devices on cancelled hibernation is not a new bug. It is caused by the ACPI _PPC call failing unless the hibernate is completed. This makes the acpi_cpufreq driver fail its init. Previously, the cpufreq device could be restored by offlining the cpu temporarily. And as a complete hibernation cycle would do this, it would be automatically restored most of the time. But after commit 5302c3fb2e62 the leftover sysfs attributes will block any device add action. Therefore offlining and onlining CPU 1 will no longer restore the cpufreq object, and a complete suspend/resume cycle will replace it with garbage. Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume") Signed-off-by: Bjørn Mork Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 4b1774f7e3ed756de003487b172553ae38b69aa8 Author: Dan Carpenter Date: Thu Nov 28 01:18:47 2013 +0300 drm/nv50/disp: min/max are reversed in nv50_crtc_gamma_set() commit bdefc8cbdfc71ea73e0573dbd2d24c0a68232218 upstream. We should be taking the minimum here instead of the max. It could lead to a buffer overflow. Fixes: 438d99e3b175 ('drm/nvd0/disp: initial crtc object implementation') Signed-off-by: Dan Carpenter a/drm/nv50_display.c b/drm/nv50_display.c index f8e66c08b11a..4e384a2f99c3 100644 Signed-off-by: Jiri Slaby commit c8a1464f668b64bb9d043ad33903f5c2d969e431 Author: Dan Carpenter Date: Thu Nov 7 10:55:43 2013 +0300 Staging: vt6655-6: potential NULL dereference in hostap_disable_hostapd() commit cb4855b49deb1acce27706ad9509d63c4fe8e988 upstream. We fixed this to use free_netdev() instead of kfree() but unfortunately free_netdev() doesn't accept NULL pointers. Smatch complains about this, it's not something I discovered through testing. Fixes: 3030d40b5036 ('staging: vt6655: use free_netdev instead of kfree') Fixes: 0a438d5b381e ('staging: vt6656: use free_netdev instead of kfree') Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 87822b39ac57dbbb3d15b713de41089b9fe01042 Author: Dan Carpenter Date: Thu Nov 7 11:04:20 2013 +0300 mfd: pm8921: Potential NULL dereference in pm8921_remove() commit d6daef95127e41233ac8e2d8472d8c0cd8687d38 upstream. We assume that "pmic" could be NULL and then dereference it two lines later. I fix this by moving the dereference inside the NULL check. Fixes: c013f0a56c56 ('mfd: Add pm8xxx irq support') Signed-off-by: Dan Carpenter Signed-off-by: Lee Jones Signed-off-by: Jiri Slaby commit 8303768920eeff9f903e1ddd84f9c08de916b56d Author: Dan Carpenter Date: Thu Nov 7 10:44:45 2013 +0300 6lowpan: release device on error path commit 78032f9b3eae3a43da9468d8ce30caa6be84f89d upstream. We recently added a new error path and it needs a dev_put(). Fixes: 7adac1ec8198 ('6lowpan: Only make 6lowpan links to IEEE802154 devices') Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9095638dfd6b9a45bf414dfcc86b88442c9cd567 Author: Ben Hutchings Date: Fri Aug 29 15:18:58 2014 -0700 ocfs2: do not write error flag to user structure we cannot copy from/to commit 2b462638e41ea62230297c21c4da9955937b7a3c upstream. If we failed to copy from the structure, writing back the flags leaks 31 bits of kernel memory (the rest of the ir_flags field). In any case, if we cannot copy from/to the structure, why should we expect putting just the flags to work? Also make sure ocfs2_info_handle_freeinode() returns the right error code if the copy_to_user() fails. Fixes: ddee5cdb70e6 ('Ocfs2: Add new OCFS2_IOC_INFO ioctl for ocfs2 v8.') Signed-off-by: Ben Hutchings Cc: Joel Becker Acked-by: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 7ae31f6afec99a5b8cb6e43d43aca648bb7c3fc7 Author: Theodore Ts'o Date: Wed Feb 15 01:26:39 2017 -0500 ext4: fix fencepost in s_first_meta_bg validation commit 2ba3e6e8afc9b6188b471f27cf2b5e3cf34e7af2 upstream. It is OK for s_first_meta_bg to be equal to the number of block group descriptor blocks. (It rarely happens, but it shouldn't cause any problems.) https://bugzilla.kernel.org/show_bug.cgi?id=194567 Fixes: 3a4b77cd47bb837b8557595ec7425f281f2ca1fe Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit bb878bdeaf6c48268322c2e4bdef0879902867aa Author: Eryu Guan Date: Thu Dec 1 15:08:37 2016 -0500 ext4: validate s_first_meta_bg at mount time commit 3a4b77cd47bb837b8557595ec7425f281f2ca1fe upstream. Ralf Spenneberg reported that he hit a kernel crash when mounting a modified ext4 image. And it turns out that kernel crashed when calculating fs overhead (ext4_calculate_overhead()), this is because the image has very large s_first_meta_bg (debug code shows it's 842150400), and ext4 overruns the memory in count_overhead() when setting bitmap buffer, which is PAGE_SIZE. ext4_calculate_overhead(): buf = get_zeroed_page(GFP_NOFS); <=== PAGE_SIZE buffer blks = count_overhead(sb, i, buf); count_overhead(): for (j = ext4_bg_num_gdb(sb, grp); j > 0; j--) { <=== j = 842150400 ext4_set_bit(EXT4_B2C(sbi, s++), buf); <=== buffer overrun count++; } This can be reproduced easily for me by this script: #!/bin/bash rm -f fs.img mkdir -p /mnt/ext4 fallocate -l 16M fs.img mke2fs -t ext4 -O bigalloc,meta_bg,^resize_inode -F fs.img debugfs -w -R "ssv first_meta_bg 842150400" fs.img mount -o loop fs.img /mnt/ext4 Fix it by validating s_first_meta_bg first at mount time, and refusing to mount if its value exceeds the largest possible meta_bg number. [js] use EXT4_HAS_INCOMPAT_FEATURE instead of new ext4_has_feature_meta_bg Reported-by: Ralf Spenneberg Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Signed-off-by: Jiri Slaby commit 8c3bdeae0aea6ceefdf50c0582c1db1e4b112f79 Author: Dan Carpenter Date: Tue Feb 18 15:20:51 2014 +0300 af_packet: remove a stray tab in packet_set_ring() commit d7cf0c34af067555737193b6c1aa7abaa677f29c upstream. At first glance it looks like there is a missing curly brace but actually the code works the same either way. I have adjusted the indenting but left the code the same. Signed-off-by: Dan Carpenter Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1f34542545978cd0c305271887e6c059b56ca88c Author: Michael Schenk Date: Thu Jan 26 11:25:04 2017 -0600 rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down commit 575ddce0507789bf9830d089557d2199d2f91865 upstream. In the function rtl_usb_start we pre-allocate a certain number of urbs for RX path but they will not be freed when calling rtl_usb_stop. This results in leaking urbs when doing ifconfig up and down. Eventually, the system has no available urbs. Signed-off-by: Michael Schenk Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Jiri Slaby commit 94e5bdac8a29138a96e560a8c8d4607e2d8d9e20 Author: Thomas Gleixner Date: Wed Feb 15 11:11:51 2017 +0100 goldfish: Sanitize the broken interrupt handler commit 6cf18e6927c0b224f972e3042fb85770d63cb9f8 upstream. This interrupt handler is broken in several ways: - It loops forever when the op code is not decodeable - It never returns IRQ_HANDLED because the only way to exit the loop returns IRQ_NONE unconditionally. The whole concept of this is broken. Creating devices in an interrupt handler is beyond any point of sanity. Make it at least behave halfways sane so accidental users do not have to deal with a hard to debug lockup. Fixes: e809c22b8fb028 ("goldfish: add the goldfish virtual bus") Reported-by: Gabriel C Signed-off-by: Thomas Gleixner Acked-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 9e8744bdd4fe66c99702e29bceb73294fb4005da Author: Thomas Gleixner Date: Wed Feb 15 11:11:50 2017 +0100 x86/platform/goldfish: Prevent unconditional loading commit 47512cfd0d7a8bd6ab71d01cd89fca19eb2093eb upstream. The goldfish platform code registers the platform device unconditionally which causes havoc in several ways if the goldfish_pdev_bus driver is enabled: - Access to the hardcoded physical memory region, which is either not available or contains stuff which is completely unrelated. - Prevents that the interrupt of the serial port can be requested - In case of a spurious interrupt it goes into a infinite loop in the interrupt handler of the pdev_bus driver (which needs to be fixed seperately). Add a 'goldfish' command line option to make the registration opt-in when the platform is compiled in. I'm seriously grumpy about this engineering trainwreck, which has seven SOBs from Intel developers for 50 lines of code. And none of them figured out that this is broken. Impressive fail! Fixes: ddd70cf93d78 ("goldfish: platform device for x86") Reported-by: Gabriel C Signed-off-by: Thomas Gleixner Acked-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 6da3d6744908e3197c2ac194b3df959adfdbc6d0 Author: Johan Hovold Date: Thu Jan 12 14:56:09 2017 +0100 USB: serial: ark3116: fix register-accessor error handling commit 9fef37d7cf170522fb354d6d0ea6de09b9b16678 upstream. The current implementation failed to detect short transfers, something which could lead to bits of the uninitialised heap transfer buffer leaking to user space. Fixes: 149fc791a452 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.") Fixes: f4c1e8d597d1 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 78777670edea6dadd3e7c111c2b2824886bb6324 Author: Johan Hovold Date: Fri Jan 13 13:21:08 2017 +0100 USB: serial: opticon: fix CTS retrieval at open commit 2eee05020a0e7ee7c04422cbacdb07859e45dce6 upstream. The opticon driver used a control request at open to trigger a CTS status notification to be sent over the bulk-in pipe. When the driver was converted to using the generic read implementation, an inverted test prevented this request from being sent, something which could lead to TIOCMGET reporting an incorrect CTS state. Reported-by: Dan Carpenter Fixes: 7a6ee2b02751 ("USB: opticon: switch to generic read implementation") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 82c7b781198dca2e9912dd61f20fb7b7104d3bed Author: Johan Hovold Date: Thu Jan 12 14:56:21 2017 +0100 USB: serial: spcp8x5: fix modem-status handling commit 5ed8d41023751bdd3546f2fe4118304357efe8d2 upstream. Make sure to detect short control transfers and return zero on success when retrieving the modem status. This fixes the TIOCMGET implementation which since e1ed212d8593 ("USB: spcp8x5: add proper modem-status support") has returned TIOCM_LE on successful retrieval, and avoids leaking bits from the stack on short transfers. This also fixes the carrier-detect implementation which since the above mentioned commit unconditionally has returned true. Fixes: e1ed212d8593 ("USB: spcp8x5: add proper modem-status support") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 0458777faa9e0b3002c7af20b5fb950bb8ff840e Author: Johan Hovold Date: Thu Feb 2 17:38:35 2017 +0100 USB: serial: ftdi_sio: fix line-status over-reporting commit a6bb1e17a39818b01b55d8e6238b4b5f06d55038 upstream. FTDI devices use a receive latency timer to periodically empty the receive buffer and report modem and line status (also when the buffer is empty). When a break or error condition is detected the corresponding status flags will be set on a packet with nonzero data payload and the flags are not updated until the break is over or further characters are received. In order to avoid over-reporting break and error conditions, these flags must therefore only be processed for packets with payload. This specifically fixes the case where after an overrun, the error condition is continuously reported and NULL-characters inserted until further data is received. Reported-by: Michael Walle Fixes: 72fda3ca6fc1 ("USB: serial: ftd_sio: implement sysrq handling on break") Fixes: 166ceb690750 ("USB: ftdi_sio: clean up line-status handling") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 7cf4bcb6f3bff2f8f73f0a2c5b8e9572e44a6e07 Author: Johan Hovold Date: Wed Jan 25 15:35:20 2017 +0100 USB: serial: ftdi_sio: fix extreme low-latency setting commit c6dce2626606ef16434802989466636bc28c1419 upstream. Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag") the FTDI driver has been using a receive latency-timer value of 1 ms instead of the device default of 16 ms. The latency timer is used to periodically empty a non-full receive buffer, but a status header is always sent when the timer expires including when the buffer is empty. This means that a two-byte bulk message is received every millisecond also for an otherwise idle port as long as it is open. Let's restore the pre-2009 behaviour which reduces the rate of the status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5 Hz) by not setting ASYNC_LOW_LATENCY by default. Anyone willing to pay the price for the minimum-latency behaviour should set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool such as setserial (e.g. setserial /dev/ttyUSB0 low_latency). Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but to set a minimal latency timer. Reported-by: Antoine Aubert Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 164e029c1313e57dc7445abf2d38907e5a4612ca Author: Johan Hovold Date: Thu Jan 12 14:56:11 2017 +0100 USB: serial: ftdi_sio: fix modem-status error handling commit 427c3a95e3e29e65f59d99aaf320d7506f3eed57 upstream. Make sure to detect short responses when fetching the modem status in order to avoid parsing uninitialised buffer data and having bits of it leak to user space. Note that we still allow for short 1-byte responses. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit d6c4af18ba5edefe8c68724f3528760851d1de2b Author: Ken Lin Date: Sat Feb 4 04:00:24 2017 +0800 USB: serial: cp210x: add new IDs for GE Bx50v3 boards commit 9a593656def0dc2f6c227851e8e602077267a5f1 upstream. Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design change. Signed-off-by: Ken Lin Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 082a7236ca46d594db12129bfa519a61ad513f3a Author: Johan Hovold Date: Thu Feb 9 12:11:41 2017 +0100 USB: serial: mos7840: fix another NULL-deref at open commit 5182c2cf2a9bfb7f066ef0bdd2bb6330b94dd74e upstream. Fix another NULL-pointer dereference at open should a malicious device lack an interrupt-in endpoint. Note that the driver has a broken check for an interrupt-in endpoint which means that an interrupt URB has never even been submitted. Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 18232b24595d484b64a1af6f91d0f666cca321ed Author: Javier Martinez Canillas Date: Mon Jan 2 11:57:20 2017 -0300 tty: serial: msm: Fix module autoload commit abe81f3b8ed2996e1712d26d38ff6b73f582c616 upstream. If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias $ After this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias alias: of:N*T*Cqcom,msm-uartdmC* alias: of:N*T*Cqcom,msm-uartdm alias: of:N*T*Cqcom,msm-uartC* alias: of:N*T*Cqcom,msm-uart Signed-off-by: Javier Martinez Canillas Acked-by: Bjorn Andersson Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit da6d7851fea3b6db2a117ce30d033b0b8055bbec Author: Maxime Jayat Date: Tue Feb 21 18:35:51 2017 +0100 net: socket: fix recvmmsg not returning error from sock_error [ Upstream commit e623a9e9dec29ae811d11f83d0074ba254aba374 ] Commit 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path"), changed the exit path of recvmmsg to always return the datagrams variable and modified the error paths to set the variable to the error code returned by recvmsg if necessary. However in the case sock_error returned an error, the error code was then ignored, and recvmmsg returned 0. Change the error path of recvmmsg to correctly return the error code of sock_error. The bug was triggered by using recvmmsg on a CAN interface which was not up. Linux 4.6 and later return 0 in this case while earlier releases returned -ENETDOWN. Fixes: 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path") Signed-off-by: Maxime Jayat Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7132afee391a91d58daa332e1851f1139889b0e3 Author: David S. Miller Date: Fri Feb 17 16:19:39 2017 -0500 irda: Fix lockdep annotations in hashbin_delete(). [ Upstream commit 4c03b862b12f980456f9de92db6d508a4999b788 ] A nested lock depth was added to the hasbin_delete() code but it doesn't actually work some well and results in tons of lockdep splats. Fix the code instead to properly drop the lock around the operation and just keep peeking the head of the hashbin queue. Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 336d459d464a2d23b5df724ae5fb5cd92bc9074c Author: Andrey Konovalov Date: Thu Feb 16 17:22:46 2017 +0100 dccp: fix freeing skb too early for IPV6_RECVPKTINFO [ Upstream commit 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 ] In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet is forcibly freed via __kfree_skb in dccp_rcv_state_process if dccp_v6_conn_request successfully returns. However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb is saved to ireq->pktopts and the ref count for skb is incremented in dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed in dccp_rcv_state_process. Fix by calling consume_skb instead of doing goto discard and therefore calling __kfree_skb. Similar fixes for TCP: fb7e2399ec17f1004c0e0ccfd17439f8759ede01 [TCP]: skb is unexpectedly freed. 0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now simply consumed Signed-off-by: Andrey Konovalov Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit fbc87738af9dc0270d89bac3706ec6bfd6238b75 Author: Anoob Soman Date: Wed Feb 15 20:25:39 2017 +0000 packet: Do not call fanout_release from atomic contexts [ Upstream commit 2bd624b4611ffee36422782d16e1c944d1351e98 ] Commit 6664498280cf ("packet: call fanout_release, while UNREGISTERING a netdev"), unfortunately, introduced the following issues. 1. calling mutex_lock(&fanout_mutex) (fanout_release()) from inside rcu_read-side critical section. rcu_read_lock disables preemption, most often, which prohibits calling sleeping functions. [ ] include/linux/rcupdate.h:560 Illegal context switch in RCU read-side critical section! [ ] [ ] rcu_scheduler_active = 1, debug_locks = 0 [ ] 4 locks held by ovs-vswitchd/1969: [ ] #0: (cb_lock){++++++}, at: [] genl_rcv+0x19/0x40 [ ] #1: (ovs_mutex){+.+.+.}, at: [] ovs_vport_cmd_del+0x4a/0x100 [openvswitch] [ ] #2: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20 [ ] #3: (rcu_read_lock){......}, at: [] packet_notifier+0x5/0x3f0 [ ] [ ] Call Trace: [ ] [] dump_stack+0x85/0xc4 [ ] [] lockdep_rcu_suspicious+0x107/0x110 [ ] [] ___might_sleep+0x57/0x210 [ ] [] __might_sleep+0x70/0x90 [ ] [] mutex_lock_nested+0x3c/0x3a0 [ ] [] ? vprintk_default+0x1f/0x30 [ ] [] ? printk+0x4d/0x4f [ ] [] fanout_release+0x1d/0xe0 [ ] [] packet_notifier+0x2f9/0x3f0 2. calling mutex_lock(&fanout_mutex) inside spin_lock(&po->bind_lock). "sleeping function called from invalid context" [ ] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620 [ ] in_atomic(): 1, irqs_disabled(): 0, pid: 1969, name: ovs-vswitchd [ ] INFO: lockdep is turned off. [ ] Call Trace: [ ] [] dump_stack+0x85/0xc4 [ ] [] ___might_sleep+0x202/0x210 [ ] [] __might_sleep+0x70/0x90 [ ] [] mutex_lock_nested+0x3c/0x3a0 [ ] [] fanout_release+0x1d/0xe0 [ ] [] packet_notifier+0x2f9/0x3f0 3. calling dev_remove_pack(&fanout->prot_hook), from inside spin_lock(&po->bind_lock) or rcu_read-side critical-section. dev_remove_pack() -> synchronize_net(), which might sleep. [ ] BUG: scheduling while atomic: ovs-vswitchd/1969/0x00000002 [ ] INFO: lockdep is turned off. [ ] Call Trace: [ ] [] dump_stack+0x85/0xc4 [ ] [] __schedule_bug+0x64/0x73 [ ] [] __schedule+0x6b/0xd10 [ ] [] schedule+0x6b/0x80 [ ] [] schedule_timeout+0x38d/0x410 [ ] [] synchronize_sched_expedited+0x53d/0x810 [ ] [] synchronize_rcu_expedited+0xe/0x10 [ ] [] synchronize_net+0x35/0x50 [ ] [] dev_remove_pack+0x13/0x20 [ ] [] fanout_release+0xbe/0xe0 [ ] [] packet_notifier+0x2f9/0x3f0 4. fanout_release() races with calls from different CPU. To fix the above problems, remove the call to fanout_release() under rcu_read_lock(). Instead, call __dev_remove_pack(&fanout->prot_hook) and netdev_run_todo will be happy that &dev->ptype_specific list is empty. In order to achieve this, I moved dev_{add,remove}_pack() out of fanout_{add,release} to __fanout_{link,unlink}. So, call to {,__}unregister_prot_hook() will make sure fanout->prot_hook is removed as well. [js] no rollover in 3.12 Fixes: 6664498280cf ("packet: call fanout_release, while UNREGISTERING a netdev") Reported-by: Eric Dumazet Signed-off-by: Anoob Soman Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6d46193d7ccae0758a8e887a6897a3e133eb9610 Author: Eric Dumazet Date: Tue Feb 14 09:03:51 2017 -0800 packet: fix races in fanout_add() [ Upstream commit d199fab63c11998a602205f7ee7ff7c05c97164b ] Multiple threads can call fanout_add() at the same time. We need to grab fanout_mutex earlier to avoid races that could lead to one thread freeing po->rollover that was set by another thread. Do the same in fanout_release(), for peace of mind, and to help us finding lockdep issues earlier. [js] no rollover in 3.12 Fixes: dc99f600698d ("packet: Add fanout support.") Fixes: 0648ab70afe6 ("packet: rollover prepare: per-socket state") Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c112a93ae0bf3906150d3c7badd8ccc2708ad031 Author: Eric Dumazet Date: Sun Feb 12 14:03:52 2017 -0800 net/llc: avoid BUG_ON() in skb_orphan() [ Upstream commit 8b74d439e1697110c5e5c600643e823eb1dd0762 ] It seems nobody used LLC since linux-3.12. Fortunately fuzzers like syzkaller still know how to run this code, otherwise it would be no fun. Setting skb->sk without skb->destructor leads to all kinds of bugs, we now prefer to be very strict about it. Ideally here we would use skb_set_owner() but this helper does not exist yet, only CAN seems to have a private helper for that. [js] take sock_efree from 62bccb8cdb6905 Fixes: 376c7311bdb6 ("net: add a temporary sanity check in skb_orphan()") Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 8cf69a631bb3a56b917390e32b95c8e5eef8d6f8 Author: Colin Ian King Date: Mon May 16 17:22:54 2016 +0100 rtc: interface: ignore expired timers when enqueuing new timers commit 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 upstream. This patch fixes a RTC wakealarm issue, namely, the event fires during hibernate and is not cleared from the list, causing hwclock to block. The current enqueuing does not trigger an alarm if any expired timers already exist on the timerqueue. This can occur when a RTC wake alarm is used to wake a machine out of hibernate and the resumed state has old expired timers that have not been removed from the timer queue. This fix skips over any expired timers and triggers an alarm if there are no pending timers on the timerqueue. Note that the skipped expired timer will get reaped later on, so there is no need to clean it up immediately. The issue can be reproduced by putting a machine into hibernate and waking it with the RTC wakealarm. Running the example RTC test program from tools/testing/selftests/timers/rtctest.c after the hibernate will block indefinitely. With the fix, it no longer blocks after the hibernate resume. BugLink: http://bugs.launchpad.net/bugs/1333569 Signed-off-by: Colin Ian King Signed-off-by: Alexandre Belloni Cc: Sumit Semwal Signed-off-by: Jiri Slaby commit 035a1e6f5d9e05bdcc3cb68d34ffb31bc9132e18 Author: Sergey Senozhatsky Date: Sat Feb 18 03:42:54 2017 -0800 printk: use rcuidle console tracepoint commit fc98c3c8c9dcafd67adcce69e6ce3191d5306c9c upstream. Use rcuidle console tracepoint because, apparently, it may be issued from an idle CPU: hw-breakpoint: Failed to enable monitor mode on CPU 0. hw-breakpoint: CPU 0 failed to disable vector catch =============================== [ ERR: suspicious RCU usage. ] 4.10.0-rc8-next-20170215+ #119 Not tainted ------------------------------- ./include/trace/events/printk.h:32 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 2, debug_locks = 0 RCU used illegally from extended quiescent state! 2 locks held by swapper/0/0: #0: (cpu_pm_notifier_lock){......}, at: [] cpu_pm_exit+0x10/0x54 #1: (console_lock){+.+.+.}, at: [] vprintk_emit+0x264/0x474 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc8-next-20170215+ #119 Hardware name: Generic OMAP4 (Flattened Device Tree) console_unlock vprintk_emit vprintk_default printk reset_ctrl_regs dbg_cpu_pm_notify notifier_call_chain cpu_pm_exit omap_enter_idle_coupled cpuidle_enter_state cpuidle_enter_state_coupled do_idle cpu_startup_entry start_kernel This RCU warning, however, is suppressed by lockdep_off() in printk(). lockdep_off() increments the ->lockdep_recursion counter and thus disables RCU_LOCKDEP_WARN() and debug_lockdep_rcu_enabled(), which want lockdep to be enabled "current->lockdep_recursion == 0". Link: http://lkml.kernel.org/r/20170217015932.11898-1-sergey.senozhatsky@gmail.com Signed-off-by: Sergey Senozhatsky Reported-by: Tony Lindgren Tested-by: Tony Lindgren Acked-by: Paul E. McKenney Acked-by: Steven Rostedt (VMware) Cc: Petr Mladek Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tony Lindgren Cc: Russell King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 66074989bb428ddc0ee7900fc02c0d9a495a1735 Author: Yang Yang Date: Fri Dec 30 16:17:55 2016 +0800 futex: Move futex_init() to core_initcall commit 25f71d1c3e98ef0e52371746220d66458eac75bc upstream. The UEVENT user mode helper is enabled before the initcalls are executed and is available when the root filesystem has been mounted. The user mode helper is triggered by device init calls and the executable might use the futex syscall. futex_init() is marked __initcall which maps to device_initcall, but there is no guarantee that futex_init() is invoked _before_ the first device init call which triggers the UEVENT user mode helper. If the user mode helper uses the futex syscall before futex_init() then the syscall crashes with a NULL pointer dereference because the futex subsystem has not been initialized yet. Move futex_init() to core_initcall so futexes are initialized before the root filesystem is mounted and the usermode helper becomes available. [ tglx: Rewrote changelog ] Signed-off-by: Yang Yang Cc: jiang.biao2@zte.com.cn Cc: jiang.zhengxiong@zte.com.cn Cc: zhong.weidong@zte.com.cn Cc: deng.huali@zte.com.cn Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1483085875-6130-1-git-send-email-yang.yang29@zte.com.cn Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby commit a1c5935238a67d621e79b837986447d7732b9f7d Author: Johannes Thumshirn Date: Tue Jan 31 10:16:00 2017 +0100 scsi: don't BUG_ON() empty DMA transfers commit fd3fc0b4d7305fa7246622dcc0dec69c42443f45 upstream. Don't crash the machine just because of an empty transfer. Use WARN_ON() combined with returning an error. Found by Dmitry Vyukov and syzkaller. [ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON() might still be a cause of excessive log spamming. NOTE! If this warning ever triggers, we may end up leaking resources, since this doesn't bother to try to clean the command up. So this WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is much worse. People really need to stop using BUG_ON() for "this shouldn't ever happen". It makes pretty much any bug worse. - Linus ] Signed-off-by: Johannes Thumshirn Reported-by: Dmitry Vyukov Cc: James Bottomley Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 405a5ed0fb6ee2a3584c25f6092cab3ba1ab4da8 Author: Mauro Carvalho Chehab Date: Tue Feb 14 17:47:57 2017 -0200 siano: make it work again with CONFIG_VMAP_STACK commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream. Reported as a Kaffeine bug: https://bugs.kde.org/show_bug.cgi?id=375811 The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. On Kernel 4.9, the default is to not accept DMA on stack anymore on x86 architecture. On other architectures, this has been a requirement since Kernel 2.2. So, after this patch, this driver should likely work fine on all archs. Tested with USB ID 2040:5510: Hauppauge Windham Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 278f2fd4efb946ae89af5937689b763b19d6d67e Author: Miklos Szeredi Date: Thu Feb 16 17:49:02 2017 +0100 vfs: fix uninitialized flags in splice_to_pipe() commit 5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac upstream. Flags (PIPE_BUF_FLAG_PACKET, PIPE_BUF_FLAG_GIFT) could remain on the unused part of the pipe ring buffer. Previously splice_to_pipe() left the flags value alone, which could result in incorrect behavior. Uninitialized flags appears to have been there from the introduction of the splice syscall. Signed-off-by: Miklos Szeredi Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit b035da658c13ce215a2ef8548867991f99f844e2 Author: Christoph Hellwig Date: Sat Jun 28 11:51:01 2014 +0200 scsi: move the nr_phys_segments assert into scsi_init_io commit 635d98b1d0cfc2ba3426a701725d31a6102c059a upstream. scsi_init_io should only be called for requests that transfer data, so move the assert that a request has segments from the callers into scsi_init_io. Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Reviewed-by: Hannes Reinecke Signed-off-by: Jiri Slaby commit f7c55cea4ed6920fae70297814f6d36b11a98c5c Author: Eric Dumazet Date: Thu Feb 9 16:15:52 2017 -0800 l2tp: do not use udp_ioctl() [ Upstream commit 72fb96e7bdbbdd4421b0726992496531060f3636 ] udp_ioctl(), as its name suggests, is used by UDP protocols, but is also used by L2TP :( L2TP should use its own handler, because it really does not look the same. SIOCINQ for instance should not assume UDP checksum or headers. Thanks to Andrey and syzkaller team for providing the report and a nice reproducer. While crashes only happen on recent kernels (after commit 7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")), this probably needs to be backported to older kernels. Fixes: 7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue") Fixes: 85584672012e ("udp: Fix udp_poll() and ioctl()") Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Acked-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 25c09419e381abe42b3005fd3661196fd860bd67 Author: WANG Cong Date: Tue Feb 7 12:59:46 2017 -0800 ping: fix a null pointer dereference [ Upstream commit 73d2c6678e6c3af7e7a42b1e78cd0211782ade32 ] Andrey reported a kernel crash: general protection fault: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 2 PID: 3880 Comm: syz-executor1 Not tainted 4.10.0-rc6+ #124 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff880060048040 task.stack: ffff880069be8000 RIP: 0010:ping_v4_push_pending_frames net/ipv4/ping.c:647 [inline] RIP: 0010:ping_v4_sendmsg+0x1acd/0x23f0 net/ipv4/ping.c:837 RSP: 0018:ffff880069bef8b8 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff880069befb90 RCX: 0000000000000000 RDX: 0000000000000018 RSI: ffff880069befa30 RDI: 00000000000000c2 RBP: ffff880069befbb8 R08: 0000000000000008 R09: 0000000000000000 R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069befab0 R13: ffff88006c624a80 R14: ffff880069befa70 R15: 0000000000000000 FS: 00007f6f7c716700(0000) GS:ffff88006de00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004a6f28 CR3: 000000003a134000 CR4: 00000000000006e0 Call Trace: inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744 sock_sendmsg_nosec net/socket.c:635 [inline] sock_sendmsg+0xca/0x110 net/socket.c:645 SYSC_sendto+0x660/0x810 net/socket.c:1687 SyS_sendto+0x40/0x50 net/socket.c:1655 entry_SYSCALL_64_fastpath+0x1f/0xc2 This is because we miss a check for NULL pointer for skb_peek() when the queue is empty. Other places already have the same check. Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit da00bdddfea8683566b2aa1afec4b1c83bdb4abf Author: Willem de Bruijn Date: Tue Feb 7 15:57:21 2017 -0500 packet: round up linear to header len [ Upstream commit 57031eb794906eea4e1c7b31dc1e2429c0af0c66 ] Link layer protocols may unconditionally pull headers, as Ethernet does in eth_type_trans. Ensure that the entire link layer header always lies in the skb linear segment. tpacket_snd has such a check. Extend this to packet_snd. Variable length link layer headers complicate the computation somewhat. Here skb->len may be smaller than dev->hard_header_len. Round up the linear length to be at least as long as the smallest of the two. [js] no virtio helpers in 3.12 Reported-by: Dmitry Vyukov Signed-off-by: Willem de Bruijn Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7a814bf5fc8b6738af64bc05d824a22d269962c6 Author: Marcelo Ricardo Leitner Date: Mon Feb 6 18:10:31 2017 -0200 sctp: avoid BUG_ON on sctp_wait_for_sndbuf [ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ] Alexander Popov reported that an application may trigger a BUG_ON in sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is waiting on it to queue more data and meanwhile another thread peels off the association being used by the first thread. This patch replaces the BUG_ON call with a proper error handling. It will return -EPIPE to the original sendmsg call, similarly to what would have been done if the association wasn't found in the first place. Acked-by: Alexander Popov Signed-off-by: Marcelo Ricardo Leitner Reviewed-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e1413a0ea8c90c4e5c63ebdcbbff620658b91182 Author: Willem de Bruijn Date: Fri Feb 3 18:20:49 2017 -0500 macvtap: read vnet_hdr_size once [ Upstream commit 837585a5375c38d40361cfe64e6fd11e1addb936 ] When IFF_VNET_HDR is enabled, a virtio_net header must precede data. Data length is verified to be greater than or equal to expected header length tun->vnet_hdr_sz before copying. Macvtap functions read the value once, but unless READ_ONCE is used, the compiler may ignore this and read multiple times. Enforce a single read and locally cached value to avoid updates between test and use. Signed-off-by: Willem de Bruijn Suggested-by: Eric Dumazet Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 5cc7e0016eba9630b22ba7dd6e3d45940790d787 Author: Willem de Bruijn Date: Fri Feb 3 18:20:48 2017 -0500 tun: read vnet_hdr_sz once [ Upstream commit e1edab87faf6ca30cd137e0795bc73aa9a9a22ec ] When IFF_VNET_HDR is enabled, a virtio_net header must precede data. Data length is verified to be greater than or equal to expected header length tun->vnet_hdr_sz before copying. Read this value once and cache locally, as it can be updated between the test and use (TOCTOU). [js] we have TUN_VNET_HDR in 3.12 Signed-off-by: Willem de Bruijn Reported-by: Dmitry Vyukov CC: Eric Dumazet Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 917c66630a6ab8a71464c9d57ea6fe14eca9b9fa Author: Eric Dumazet Date: Fri Feb 3 14:59:38 2017 -0800 tcp: avoid infinite loop in tcp_splice_read() [ Upstream commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82 ] Splicing from TCP socket is vulnerable when a packet with URG flag is received and stored into receive queue. __tcp_splice_read() returns 0, and sk_wait_data() immediately returns since there is the problematic skb in queue. This is a nice way to burn cpu (aka infinite loop) and trigger soft lockups. Again, this gem was found by syzkaller tool. Fixes: 9c55e01c0cc8 ("[TCP]: Splice receive support.") Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Cc: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1ae4b12d7643d9bdde764ef671440a8eaf6cfd55 Author: Eric Dumazet Date: Sat Feb 4 23:18:55 2017 -0800 ip6_gre: fix ip6gre_err() invalid reads [ Upstream commit 7892032cfe67f4bde6fc2ee967e45a8fbaf33756 ] Andrey Konovalov reported out of bound accesses in ip6gre_err() If GRE flags contains GRE_KEY, the following expression *(((__be32 *)p) + (grehlen / 4) - 1) accesses data ~40 bytes after the expected point, since grehlen includes the size of IPv6 headers. Let's use a "struct gre_base_hdr *greh" pointer to make this code more readable. p[1] becomes greh->protocol. grhlen is the GRE header length. Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 0bccd6e118c3613c9addaa053b4a6e8670f3940c Author: Eric Dumazet Date: Fri Feb 3 00:03:26 2017 -0800 netlabel: out of bound access in cipso_v4_validate() [ Upstream commit d71b7896886345c53ef1d84bda2bc758554f5d61 ] syzkaller found another out of bound access in ip_options_compile(), or more exactly in cipso_v4_validate() Fixes: 20e2a8648596 ("cipso: handle CIPSO options correctly when NetLabel is disabled") Fixes: 446fda4f2682 ("[NetLabel]: CIPSOv4 engine") Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Cc: Paul Moore Acked-by: Paul Moore Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e5a82d662d35933e5511c0280e8513d38d9d4fa0 Author: Eric Dumazet Date: Sat Feb 4 11:16:52 2017 -0800 ipv4: keep skb->dst around in presence of IP options [ Upstream commit 34b2cef20f19c87999fff3da4071e66937db9644 ] Andrey Konovalov got crashes in __ip_options_echo() when a NULL skb->dst is accessed. ipv4_pktinfo_prepare() should not drop the dst if (evil) IP options are present. We could refine the test to the presence of ts_needtime or srr, but IP options are not often used, so let's be conservative. Thanks to syzkaller team for finding this bug. Fixes: d826eb14ecef ("ipv4: PKTINFO doesnt need dst reference") Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 33b07484cb199320795a9dd6cca52a25a641085a Author: Eric Dumazet Date: Thu Feb 2 10:31:35 2017 -0800 net: use a work queue to defer net_disable_timestamp() work [ Upstream commit 5fa8bbda38c668e56b0c6cdecced2eac2fe36dec ] Dmitry reported a warning [1] showing that we were calling net_disable_timestamp() -> static_key_slow_dec() from a non process context. Grabbing a mutex while holding a spinlock or rcu_read_lock() is not allowed. As Cong suggested, we now use a work queue. It is possible netstamp_clear() exits while netstamp_needed_deferred is not zero, but it is probably not worth trying to do better than that. netstamp_needed_deferred atomic tracks the exact number of deferred decrements. [1] [ INFO: suspicious RCU usage. ] 4.10.0-rc5+ #192 Not tainted ------------------------------- ./include/linux/rcupdate.h:561 Illegal context switch in RCU read-side critical section! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 0 2 locks held by syz-executor14/23111: #0: (sk_lock-AF_INET6){+.+.+.}, at: [] lock_sock include/net/sock.h:1454 [inline] #0: (sk_lock-AF_INET6){+.+.+.}, at: [] rawv6_sendmsg+0x1e65/0x3ec0 net/ipv6/raw.c:919 #1: (rcu_read_lock){......}, at: [] nf_hook include/linux/netfilter.h:201 [inline] #1: (rcu_read_lock){......}, at: [] __ip6_local_out+0x258/0x840 net/ipv6/output_core.c:160 stack backtrace: CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4452 rcu_preempt_sleep_check include/linux/rcupdate.h:560 [inline] ___might_sleep+0x560/0x650 kernel/sched/core.c:7748 __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739 mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752 atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060 __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149 static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174 net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728 sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403 __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441 sk_destruct+0x47/0x80 net/core/sock.c:1460 __sk_free+0x57/0x230 net/core/sock.c:1468 sock_wfree+0xae/0x120 net/core/sock.c:1645 skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655 skb_release_all+0x15/0x60 net/core/skbuff.c:668 __kfree_skb+0x15/0x20 net/core/skbuff.c:684 kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705 inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304 inet_frag_put include/net/inet_frag.h:133 [inline] nf_ct_frag6_gather+0x1106/0x3840 net/ipv6/netfilter/nf_conntrack_reasm.c:617 ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68 nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline] nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310 nf_hook include/linux/netfilter.h:212 [inline] __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160 ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170 ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722 ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742 rawv6_push_pending_frames net/ipv6/raw.c:613 [inline] rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744 sock_sendmsg_nosec net/socket.c:635 [inline] sock_sendmsg+0xca/0x110 net/socket.c:645 sock_write_iter+0x326/0x600 net/socket.c:848 do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695 do_readv_writev+0x42c/0x9b0 fs/read_write.c:872 vfs_writev+0x87/0xc0 fs/read_write.c:911 do_writev+0x110/0x2c0 fs/read_write.c:944 SYSC_writev fs/read_write.c:1017 [inline] SyS_writev+0x27/0x30 fs/read_write.c:1014 entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP: 0033:0x445559 RSP: 002b:00007f6f46fceb58 EFLAGS: 00000292 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000445559 RDX: 0000000000000001 RSI: 0000000020f1eff0 RDI: 0000000000000005 RBP: 00000000006e19c0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000700000 R13: 0000000020f59000 R14: 0000000000000015 R15: 0000000000020400 BUG: sleeping function called from invalid context at kernel/locking/mutex.c:752 in_atomic(): 1, irqs_disabled(): 0, pid: 23111, name: syz-executor14 INFO: lockdep is turned off. CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780 __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739 mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752 atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060 __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149 static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174 net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728 sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403 __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441 sk_destruct+0x47/0x80 net/core/sock.c:1460 __sk_free+0x57/0x230 net/core/sock.c:1468 sock_wfree+0xae/0x120 net/core/sock.c:1645 skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655 skb_release_all+0x15/0x60 net/core/skbuff.c:668 __kfree_skb+0x15/0x20 net/core/skbuff.c:684 kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705 inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304 inet_frag_put include/net/inet_frag.h:133 [inline] nf_ct_frag6_gather+0x1106/0x3840 net/ipv6/netfilter/nf_conntrack_reasm.c:617 ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68 nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline] nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310 nf_hook include/linux/netfilter.h:212 [inline] __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160 ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170 ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722 ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742 rawv6_push_pending_frames net/ipv6/raw.c:613 [inline] rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744 sock_sendmsg_nosec net/socket.c:635 [inline] sock_sendmsg+0xca/0x110 net/socket.c:645 sock_write_iter+0x326/0x600 net/socket.c:848 do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695 do_readv_writev+0x42c/0x9b0 fs/read_write.c:872 vfs_writev+0x87/0xc0 fs/read_write.c:911 do_writev+0x110/0x2c0 fs/read_write.c:944 SYSC_writev fs/read_write.c:1017 [inline] SyS_writev+0x27/0x30 fs/read_write.c:1014 entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP: 0033:0x445559 Fixes: b90e5794c5bd ("net: dont call jump_label_dec from irq context") Suggested-by: Cong Wang Reported-by: Dmitry Vyukov Signed-off-by: Eric Dumazet