commit 310ca59d1f1ced193c296e2ecd867b9f7fb1d297 Author: Greg Kroah-Hartman Date: Mon Jul 11 09:30:07 2016 -0700 Linux 4.6.4 commit 07a94f85730d07c9cf839a241eea34f719d48c2e Author: Steinar H. Gunderson Date: Tue May 24 20:13:15 2016 +0200 usb: dwc3: exynos: Fix deferred probing storm. commit 4879efb34f7d49235fac334d76d9c6a77a021413 upstream. dwc3-exynos has two problems during init if the regulators are slow to come up (for instance if the I2C bus driver is not on the initramfs) and return probe deferral. First, every time this happens, the driver leaks the USB phys created; they need to be deallocated on error. Second, since the phy devices are created before the regulators fail, this means that there's a new device to re-trigger deferred probing, which causes it to essentially go into a busy loop of re-probing the device until the regulators come up. Move the phy creation to after the regulators have succeeded, and also fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs which doesn't contain the I2C driver), this reduces the number of probe attempts (for each of the two controllers) from more than 2000 to eight. Signed-off-by: Steinar H. Gunderson Reviewed-by: Krzysztof Kozlowski Reviewed-by: Vivek Gautam Fixes: d720f057fda4 ("usb: dwc3: exynos: add nop transceiver support") Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 094f827e836e7172cdd16bbe5e195d919013acbf Author: Thierry Reding Date: Thu May 26 17:23:29 2016 +0200 usb: host: ehci-tegra: Grab the correct UTMI pads reset commit f8a15a9650694feaa0dabf197b0c94d37cd3fb42 upstream. There are three EHCI controllers on Tegra SoCs, each with its own reset line. However, the first controller contains a set of UTMI configuration registers that are shared with its siblings. These registers will only be reset as part of the first controller's reset. For proper operation it must be ensured that the UTMI configuration registers are reset before any of the EHCI controllers are enabled, irrespective of the probe order. Commit a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB") introduced code that ensures the first controller is always reset before setting up any of the controllers, and is never again reset afterwards. This code, however, grabs the wrong reset. Each EHCI controller has two reset controls attached: 1) the USB controller reset and 2) the UTMI pads reset (really the first controller's reset). In order to reset the UTMI pads registers the code must grab the second reset, but instead it grabbing the first. Fixes: a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB") Acked-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 72d43ddecbe66537e4622874fca894237fce142f Author: Bin Liu Date: Thu May 26 11:43:45 2016 -0500 usb: gadget: fix spinlock dead lock in gadgetfs commit d246dcb2331c5783743720e6510892eb1d2801d9 upstream. [ 40.467381] ============================================= [ 40.473013] [ INFO: possible recursive locking detected ] [ 40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted [ 40.483466] --------------------------------------------- [ 40.489098] usb/733 is trying to acquire lock: [ 40.493734] (&(&dev->lock)->rlock){-.....}, at: [] ep0_complete+0x18/0xdc [gadgetfs] [ 40.502882] [ 40.502882] but task is already holding lock: [ 40.508967] (&(&dev->lock)->rlock){-.....}, at: [] ep0_read+0x20/0x5e0 [gadgetfs] [ 40.517811] [ 40.517811] other info that might help us debug this: [ 40.524623] Possible unsafe locking scenario: [ 40.524623] [ 40.530798] CPU0 [ 40.533346] ---- [ 40.535894] lock(&(&dev->lock)->rlock); [ 40.540088] lock(&(&dev->lock)->rlock); [ 40.544284] [ 40.544284] *** DEADLOCK *** [ 40.544284] [ 40.550461] May be due to missing lock nesting notation [ 40.550461] [ 40.557544] 2 locks held by usb/733: [ 40.561271] #0: (&f->f_pos_lock){+.+.+.}, at: [] __fdget_pos+0x40/0x48 [ 40.569219] #1: (&(&dev->lock)->rlock){-.....}, at: [] ep0_read+0x20/0x5e0 [gadgetfs] [ 40.578523] [ 40.578523] stack backtrace: [ 40.583075] CPU: 0 PID: 733 Comm: usb Not tainted 4.6.0-08691-g7f3db9a #37 [ 40.590246] Hardware name: Generic AM33XX (Flattened Device Tree) [ 40.596625] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 40.604718] [] (show_stack) from [] (dump_stack+0xb0/0xe4) [ 40.612267] [] (dump_stack) from [] (__lock_acquire+0xf68/0x1994) [ 40.620440] [] (__lock_acquire) from [] (lock_acquire+0xd8/0x238) [ 40.628621] [] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x38/0x4c) [ 40.637440] [] (_raw_spin_lock_irqsave) from [] (ep0_complete+0x18/0xdc [gadgetfs]) [ 40.647339] [] (ep0_complete [gadgetfs]) from [] (musb_g_giveback+0x118/0x1b0 [musb_hdrc]) [ 40.657842] [] (musb_g_giveback [musb_hdrc]) from [] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc]) [ 40.668772] [] (musb_g_ep0_queue [musb_hdrc]) from [] (ep0_read+0x544/0x5e0 [gadgetfs]) [ 40.678963] [] (ep0_read [gadgetfs]) from [] (__vfs_read+0x20/0x110) [ 40.687414] [] (__vfs_read) from [] (vfs_read+0x88/0x114) [ 40.694864] [] (vfs_read) from [] (SyS_read+0x44/0x9c) [ 40.702051] [] (SyS_read) from [] (ret_fast_syscall+0x0/0x1c) This is caused by the spinlock bug in ep0_read(). Fix the two other deadlock sources in gadgetfs_setup() too. Signed-off-by: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 293596074c6e68cf328ee6ca5ac88bc042567281 Author: Sudip Mukherjee Date: Mon May 30 19:16:33 2016 +0530 USB: mos7720: delete parport commit dcb21ad4385731b7fc3ef39d255685f2f63c8c5d upstream. parport subsystem has introduced parport_del_port() to delete a port when it is going away. Without parport_del_port() the registered port will not be unregistered. To reproduce and verify the error: Command to be used is : ls /sys/bus/parport/devices 1) without the device attached there is no output as there is no registered parport. 2) Attach the device, and the command will show "parport0". 3) Remove the device and the command still shows "parport0". 4) Attach the device again and we get "parport1". With the patch applied: 1) without the device attached there is no output as there is no registered parport. 2) Attach the device, and the command will show "parport0". 3) Remove the device and there is no output as "parport0" is now removed. 4) Attach device again to get "parport0" again. Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit ab4d7f6ccd76513da9c2909aa5a2d595cba748e7 Author: Mathias Nyman Date: Wed Jun 1 18:09:08 2016 +0300 xhci: Fix handling timeouted commands on hosts in weird states. commit 3425aa03f484d45dc21e0e791c2f6c74ea656421 upstream. If commands timeout we mark them for abortion, then stop the command ring, and turn the commands to no-ops and finally restart the command ring. If the host is working properly the no-op commands will finish and pending completions are called. If we notice the host is failing, driver clears the command ring and completes, deletes and frees all pending commands. There are two separate cases reported where host is believed to work properly but is not. In the first case we successfully stop the ring but no abort or stop command ring event is ever sent and host locks up. The second case is if a host is removed, command times out and driver believes the ring is stopped, and assumes it will be restarted, but actually ends up timing out on the same command forever. If one of the pending commands has the xhci->mutex held it will block xhci_stop() in the remove codepath which otherwise would cleanup pending commands. Add a check that clears all pending commands in case host is removed, or we are stuck timing out on the same command. Also restart the command timeout timer when stopping the command ring to ensure we recive an ring stop/abort event. Tested-by: Joe Lawrence Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit cbe6a061de8d27494254a4929ed750962f8feec1 Author: Hans de Goede Date: Wed Jun 1 21:01:29 2016 +0200 USB: xhci: Add broken streams quirk for Frescologic device id 1009 commit d95815ba6a0f287213118c136e64d8c56daeaeab upstream. I got one of these cards for testing uas with, it seems that with streams it dma-s all over the place, corrupting memory. On my first tests it managed to dma over the BIOS of the motherboard somehow and completely bricked it. Tests on another motherboard show that it does work with streams disabled. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 89f707fd51859e23c18de0140b305b529bdcc217 Author: Thomas Petazzoni Date: Wed Jun 1 18:09:09 2016 +0300 usb: xhci-plat: properly handle probe deferral for devm_clk_get() commit de95c40d5beaa47f6dc8fe9ac4159b4672b51523 upstream. On some platforms, the clocks might be registered by a platform driver. When this is the case, the clock platform driver may very well be probed after xhci-plat, in which case the first probe() invocation of xhci-plat will receive -EPROBE_DEFER as the return value of devm_clk_get(). The current code handles that as a normal error, and simply assumes that this means that the system doesn't have a clock for the XHCI controller, and continues probing without calling clk_prepare_enable(). Unfortunately, this doesn't work on systems where the XHCI controller does have a clock, but that clock is provided by another platform driver. In order to fix this situation, we handle the -EPROBE_DEFER error condition specially, and abort the XHCI controller probe(). It will be retried later automatically, the clock will be available, devm_clk_get() will succeed, and the probe() will continue with the clock prepared and enabled as expected. In practice, such issue is seen on the ARM64 Marvell 7K/8K platform, where the clocks are registered by a platform driver. Signed-off-by: Thomas Petazzoni Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 5149a103c8803ede888a79fe38c79b5619753721 Author: Gabriel Krisman Bertazi Date: Wed Jun 1 18:09:07 2016 +0300 xhci: Cleanup only when releasing primary hcd commit 27a41a83ec54d0edfcaf079310244e7f013a7701 upstream. Under stress occasions some TI devices might not return early when reading the status register during the quirk invocation of xhci_irq made by usb_hcd_pci_remove. This means that instead of returning, we end up handling this interruption in the middle of a shutdown. Since xhci->event_ring has already been freed in xhci_mem_cleanup, we end up accessing freed memory, causing the Oops below. commit 8c24d6d7b09d ("usb: xhci: stop everything on the first call to xhci_stop") is the one that changed the instant in which we clean up the event queue when stopping a device. Before, we didn't call xhci_mem_cleanup at the first time xhci_stop is executed (for the shared HCD), instead, we only did it after the invocation for the primary HCD, much later at the removal path. The code flow for this oops looks like this: xhci_pci_remove() usb_remove_hcd(xhci->shared) xhci_stop(xhci->shared) xhci_halt() xhci_mem_cleanup(xhci); // Free the event_queue usb_hcd_pci_remove(primary) xhci_irq() // Access the event_queue if STS_EINT is set. Crash. xhci_stop() xhci_halt() // return early The fix modifies xhci_stop to only cleanup the xhci data when releasing the primary HCD. This way, we still have the event_queue configured when invoking xhci_irq. We still halt the device on the first call to xhci_stop, though. I could reproduce this issue several times on the mainline kernel by doing a bind-unbind stress test with a specific storage gadget attached. I also ran the same test over-night with my patch applied and didn't observe the issue anymore. [ 113.334124] Unable to handle kernel paging request for data at address 0x00000028 [ 113.335514] Faulting instruction address: 0xd00000000d4f767c [ 113.336839] Oops: Kernel access of bad area, sig: 11 [#1] [ 113.338214] SMP NR_CPUS=1024 NUMA PowerNV [c000000efe47ba90] c000000000720850 usb_hcd_irq+0x50/0x80 [c000000efe47bac0] c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0 [c000000efe47bb00] d00000000daf0128 xhci_pci_remove+0x78/0xb0 [xhci_pci] [c000000efe47bb30] c00000000055cf70 pci_device_remove+0x70/0x110 [c000000efe47bb70] c00000000061c6bc __device_release_driver+0xbc/0x190 [c000000efe47bba0] c00000000061c7d0 device_release_driver+0x40/0x70 [c000000efe47bbd0] c000000000619510 unbind_store+0x120/0x150 [c000000efe47bc20] c0000000006183c4 drv_attr_store+0x64/0xa0 [c000000efe47bc60] c00000000039f1d0 sysfs_kf_write+0x80/0xb0 [c000000efe47bca0] c00000000039e14c kernfs_fop_write+0x18c/0x1f0 [c000000efe47bcf0] c0000000002e962c __vfs_write+0x6c/0x190 [c000000efe47bd90] c0000000002eab40 vfs_write+0xc0/0x200 [c000000efe47bde0] c0000000002ec85c SyS_write+0x6c/0x110 [c000000efe47be30] c000000000009260 system_call+0x38/0x108 Signed-off-by: Gabriel Krisman Bertazi Cc: Roger Quadros Cc: joel@jms.id.au Reviewed-by: Roger Quadros Tested-by: Joel Stanley Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 7d5209c8b4ceb5cc0e9277be7fee8d870439856d Author: Bin Liu Date: Tue May 31 10:05:25 2016 -0500 usb: musb: host: correct cppi dma channel for isoch transfer commit 04471eb8c3158c0ad9df4b24da845a63b2e8f23a upstream. Incorrect cppi dma channel is referenced in musb_rx_dma_iso_cppi41(), which causes kernel NULL pointer reference oops later when calling cppi41_dma_channel_program(). Fixes: 069a3fd (usb: musb: Remove ifdefs for musb_host_rx in musb_host.c part1) Reported-by: Matwey V. Kornilov Acked-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 5a8d728bebab6a6609d87d8bcfe9528473e3f746 Author: Andrew Goodbody Date: Tue May 31 10:05:26 2016 -0500 usb: musb: Ensure rx reinit occurs for shared_fifo endpoints commit f3eec0cf784e0d6c47822ca6b66df3d5812af7e6 upstream. shared_fifo endpoints would only get a previous tx state cleared out, the rx state was only cleared for non shared_fifo endpoints Change this so that the rx state is cleared for all endpoints. This addresses an issue that resulted in rx packets being dropped silently. Signed-off-by: Andrew Goodbody Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit b79d89e3ea2732c475531c348210a56d64fef50d Author: Andrew Goodbody Date: Tue May 31 10:05:27 2016 -0500 usb: musb: Stop bulk endpoint while queue is rotated commit 7b2c17f829545df27a910e8d82e133c21c9a8c9c upstream. Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was reprogrammed resulting in a warning about such data from musb_rx_reinit before it was thrown away. The data thrown away was a valid packet that had been correctly ACKed which meant the host and device got out of sync. Signed-off-by: Andrew Goodbody Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 7adf3cd844622756befc599ef729b87590259876 Author: Bin Liu Date: Tue May 31 10:05:24 2016 -0500 usb: musb: only restore devctl when session was set in backup commit 84ac5d1140f716a616522f952734e850448d2556 upstream. If the session bit was not set in the backup of devctl register, restoring devctl would clear the session bit. Therefor, only restore devctl register when the session bit was set in the backup. This solves the device enumeration failure in otg mode exposed by commit 56f487c (PM / Runtime: Update last_busy in rpm_resume). Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit c9da581d90e954c26224b131592be78666c845c1 Author: Hans de Goede Date: Thu May 19 17:12:20 2016 +0200 usb: quirks: Add no-lpm quirk for Acer C120 LED Projector commit 32cb0b37098f4beeff5ad9e325f11b42a6ede56c upstream. The Acer C120 LED Projector is a USB-3 connected pico projector which takes both its power and video data from USB-3. In combination with some hubs this device does not play well with lpm, so disable lpm for it. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit a0c0e9f072298cedf22ce13e916ccf1f929bb513 Author: Hans de Goede Date: Thu May 19 17:12:19 2016 +0200 usb: quirks: Fix sorting commit 81099f97bd31e25ff2719a435b1860fc3876122f upstream. Properly sort all the entries by vendor id. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 5fbbd1bce002d6764ded76bcbd86b3fa311ea85c Author: Hans de Goede Date: Tue May 31 09:18:03 2016 +0200 USB: uas: Fix slave queue_depth not being set commit 593224ea77b1ca842f45cf76f4deeef44dfbacd1 upstream. Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level") removed the scsi_change_queue_depth() call from uas_slave_configure() assuming that the slave would inherit the host's queue_depth, which that commit sets to the same value. This is incorrect, without the scsi_change_queue_depth() call the slave's queue_depth defaults to 1, introducing a performance regression. This commit restores the call, fixing the performance regression. Fixes: 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level") Reported-by: Tom Yan Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit a7b341d255f5795759f2a7d2bac6f1e15652519b Author: Mathias Krause Date: Wed Jun 22 20:29:37 2016 +0200 crypto: user - re-add size check for CRYPTO_MSG_GETALG commit 055ddaace03580455a7b7dbea8e93d62acee61fc upstream. Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG") accidentally removed the minimum size check for CRYPTO_MSG_GETALG netlink messages. This allows userland to send a truncated CRYPTO_MSG_GETALG message as short as a netlink header only making crypto_report() operate on uninitialized memory by accessing data beyond the end of the netlink message. Fix this be re-adding the minimum required size of CRYPTO_MSG_GETALG messages to the crypto_msg_min[] array. Fixes: 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG") Signed-off-by: Mathias Krause Cc: Steffen Klassert Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 99aaa4f9de8ccd345b67b137a978abc8a5556ec1 Author: Linus Walleij Date: Wed Jun 8 14:56:39 2016 +0200 crypto: ux500 - memmove the right size commit 19ced623db2fe91604d69f7d86b03144c5107739 upstream. The hash buffer is really HASH_BLOCK_SIZE bytes, someone must have thought that memmove takes n*u32 words by mistake. Tests work as good/bad as before after this patch. Cc: Joakim Bech Reported-by: David Binderman Signed-off-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e4559fa118699156d0f5c78eb80fe5c549878574 Author: Anton Blanchard Date: Fri Jun 10 16:47:03 2016 +1000 crypto: vmx - Increase priority of aes-cbc cipher commit 12d3f49e1ffbbf8cbbb60acae5a21103c5c841ac upstream. All of the VMX AES ciphers (AES, AES-CBC and AES-CTR) are set at priority 1000. Unfortunately this means we never use AES-CBC and AES-CTR, because the base AES-CBC cipher that is implemented on top of AES inherits its priority. To fix this, AES-CBC and AES-CTR have to be a higher priority. Set them to 2000. Testing on a POWER8 with: cryptsetup benchmark --cipher aes --key-size 256 Shows decryption speed increase from 402.4 MB/s to 3069.2 MB/s, over 7x faster. Thanks to Mike Strosaker for helping me debug this issue. Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module") Signed-off-by: Anton Blanchard Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 863ac9f67b9c7956f98461ceec0cb222a6cdfd8a Author: Basil Gunn Date: Thu Jun 16 09:42:30 2016 -0700 AX.25: Close socket connection on session completion [ Upstream commit 4a7d99ea1b27734558feb6833f180cd38a159940 ] A socket connection made in ax.25 is not closed when session is completed. The heartbeat timer is stopped prematurely and this is where the socket gets closed. Allow heatbeat timer to run to close socket. Symptom occurs in kernels >= 4.2.0 Originally sent 6/15/2016. Resend with distribution list matching scripts/maintainer.pl output. Signed-off-by: Basil Gunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cc86d18b2f98ff01420f5d30b009e090d543e2ab Author: David Barroso Date: Tue Jun 28 11:16:43 2016 +0300 neigh: Explicitly declare RCU-bh read side critical section in neigh_xmit() [ Upstream commit b560f03ddfb072bca65e9440ff0dc4f9b1d1f056 ] neigh_xmit() expects to be called inside an RCU-bh read side critical section, and while one of its two current callers gets this right, the other one doesn't. More specifically, neigh_xmit() has two callers, mpls_forward() and mpls_output(), and while both callers call neigh_xmit() under rcu_read_lock(), this provides sufficient protection for neigh_xmit() only in the case of mpls_forward(), as that is always called from softirq context and therefore doesn't need explicit BH protection, while mpls_output() can be called from process context with softirqs enabled. When mpls_output() is called from process context, with softirqs enabled, we can be preempted by a softirq at any time, and RCU-bh considers the completion of a softirq as signaling the end of any pending read-side critical sections, so if we do get a softirq while we are in the part of neigh_xmit() that expects to be run inside an RCU-bh read side critical section, we can end up with an unexpected RCU grace period running right in the middle of that critical section, making things go boom. This patch fixes this impedance mismatch in the callee, by making neigh_xmit() always take rcu_read_{,un}lock_bh() around the code that expects to be treated as an RCU-bh read side critical section, as this seems a safer option than fixing it in the callers. Fixes: 4fd3d7d9e868f ("neigh: Add helper function neigh_xmit") Signed-off-by: David Barroso Signed-off-by: Lennert Buytenhek Acked-by: David Ahern Acked-by: Robert Shearman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5f97d2700356770686f89b2907de7f3b916e5ff9 Author: Daniel Borkmann Date: Mon Jun 27 21:38:11 2016 +0200 bpf, perf: delay release of BPF prog after grace period [ Upstream commit ceb56070359b7329b5678b5d95a376fcb24767be ] Commit dead9f29ddcc ("perf: Fix race in BPF program unregister") moved destruction of BPF program from free_event_rcu() callback to __free_event(), which is problematic if used with tail calls: if prog A is attached as trace event directly, but at the same time present in a tail call map used by another trace event program elsewhere, then we need to delay destruction via RCU grace period since it can still be in use by the program doing the tail call (the prog first needs to be dropped from the tail call map, then trace event with prog A attached destroyed, so we get immediate destruction). Fixes: dead9f29ddcc ("perf: Fix race in BPF program unregister") Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Cc: Jann Horn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c369d2d6e7cda5e53d1b06ebfc2bc3921f0472a4 Author: Willem de Bruijn Date: Fri Jun 24 16:02:35 2016 -0400 sock_diag: do not broadcast raw socket destruction [ Upstream commit 9a0fee2b552b1235fb1706ae1fc664ae74573be8 ] Diag intends to broadcast tcp_sk and udp_sk socket destruction. Testing sk->sk_protocol for IPPROTO_TCP/IPPROTO_UDP alone is not sufficient for this. Raw sockets can have the same type. Add a test for sk->sk_type. Fixes: eb4cb008529c ("sock_diag: define destruction multicast groups") Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit aaa7fa15086cc4332c73d5ecf7fa1ab71c8e4ae9 Author: daniel Date: Fri Jun 24 12:35:18 2016 +0200 Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address [ Upstream commit 0888d5f3c0f183ea6177355752ada433d370ac89 ] The bridge is falsly dropping ipv6 mulitcast packets if there is: 1. No ipv6 address assigned on the brigde. 2. No external mld querier present. 3. The internal querier enabled. When the bridge fails to build mld queries, because it has no ipv6 address, it slilently returns, but keeps the local querier enabled. This specific case causes confusing packet loss. Ipv6 multicast snooping can only work if: a) An external querier is present OR b) The bridge has an ipv6 address an is capable of sending own queries Otherwise it has to forward/flood the ipv6 multicast traffic, because snooping cannot work. This patch fixes the issue by adding a flag to the bridge struct that indicates that there is currently no ipv6 address assinged to the bridge and returns a false state for the local querier in __br_multicast_querier_exists(). Special thanks to Linus Lüssing. Fixes: d1d81d4c3dd8 ("bridge: check return value of ipv6_dev_get_saddr()") Signed-off-by: Daniel Danzberger Acked-by: Linus Lüssing Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9d262c8bac637d722453c170fc6819ab7f118bc9 Author: Tom Goff Date: Thu Jun 23 16:11:57 2016 -0400 ipmr/ip6mr: Initialize the last assert time of mfc entries. [ Upstream commit 70a0dec45174c976c64b4c8c1d0898581f759948 ] This fixes wrong-interface signaling on 32-bit platforms for entries created when jiffies > 2^31 + MFC_ASSERT_THRESH. Signed-off-by: Tom Goff Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 16e0f188281a37de74bb3e0ed007a8a24c5901b3 Author: Eric Dumazet Date: Mon Jun 20 15:00:43 2016 -0700 netem: fix a use after free [ Upstream commit 21de12ee5568fd1aec47890c72967abf791ac80a ] If the packet was dropped by lower qdisc, then we must not access it later. Save qdisc_pkt_len(skb) in a temp variable. Fixes: 2ccccf5fb43f ("net_sched: update hierarchical backlog too") Signed-off-by: Eric Dumazet Cc: WANG Cong Cc: Jamal Hadi Salim Cc: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5438c1a50370c598cc536240b4e2c478a118d19b Author: Herbert Xu Date: Sat Jun 18 13:03:36 2016 +0800 esp: Fix ESN generation under UDP encapsulation [ Upstream commit 962fcef33b03395051367181a0549d29d109d9a4 ] Blair Steven noticed that ESN in conjunction with UDP encapsulation is broken because we set the temporary ESP header to the wrong spot. This patch fixes this by first of all using the right spot, i.e., 4 bytes off the real ESP header, and then saving this information so that after encryption we can restore it properly. Fixes: 7021b2e1cddd ("esp4: Switch to new AEAD interface") Reported-by: Blair Steven Signed-off-by: Herbert Xu Acked-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c122056d15b462a9597606acce8f635b258faf2a Author: Jiri Slaby Date: Mon Jun 20 11:36:28 2016 +0200 kcm: fix /proc memory leak [ Upstream commit d19af0a76444fde629667ecb823c0ee28f9f67d8 ] Every open of /proc/net/kcm leaks 16 bytes of memory as is reported by kmemleak: unreferenced object 0xffff88059c0e3458 (size 192): comm "cat", pid 1401, jiffies 4294935742 (age 310.720s) hex dump (first 32 bytes): 28 45 71 96 05 88 ff ff 00 10 00 00 00 00 00 00 (Eq............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmem_cache_alloc_trace+0x16e/0x230 [] seq_open+0x79/0x1d0 [] kcm_seq_open+0x0/0x30 [kcm] [] seq_open+0x79/0x1d0 [] __seq_open_private+0x2f/0xa0 [] seq_open_net+0x38/0xa0 ... It is caused by a missing free in the ->release path. So fix it by providing seq_release_net as the ->release method. Signed-off-by: Jiri Slaby Fixes: cd6e111bf5 (kcm: Add statistics and proc interfaces) Cc: "David S. Miller" Cc: Tom Herbert Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 28dcda8b29d9adbeeefd64daa1abc352eb4b0da1 Author: Simon Horman Date: Thu Jun 16 17:06:19 2016 +0900 sit: correct IP protocol used in ipip6_err [ Upstream commit d5d8760b78d0cfafe292f965f599988138b06a70 ] Since 32b8a8e59c9c ("sit: add IPv4 over IPv4 support") ipip6_err() may be called for packets whose IP protocol is IPPROTO_IPIP as well as those whose IP protocol is IPPROTO_IPV6. In the case of IPPROTO_IPIP packets the correct protocol value is not passed to ipv4_update_pmtu() or ipv4_redirect(). This patch resolves this problem by using the IP protocol of the packet rather than a hard-coded value. This appears to be consistent with the usage of the protocol of a packet by icmp_socket_deliver() the caller of ipip6_err(). I was able to exercise the redirect case by using a setup where an ICMP redirect was received for the destination of the encapsulated packet. However, it appears that although incorrect the protocol field is not used in this case and thus no problem manifests. On inspection it does not appear that a problem will manifest in the fragmentation needed/update pmtu case either. In short I believe this is a cosmetic fix. None the less, the use of IPPROTO_IPV6 seems wrong and confusing. Reviewed-by: Dinan Gunawardena Signed-off-by: Simon Horman Acked-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bc7dcc5201e70d9d0a2767216076870355f94a0f Author: Jason A. Donenfeld Date: Wed Jun 15 11:14:53 2016 +0200 net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG [ Upstream commit daddef76c3deaaa7922f9d7b18edbf0a061215c3 ] The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG case was added with 2c94b5373 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the usual definition of the dynamic_pr_debug macro, but alter it by adding a call to "net_ratelimit()" in the if statement. This is, in fact, the correct approach. However, while doing this, the author of the commit forgot to surround fmt by pr_fmt, resulting in unprefixed log messages appearing in the console. So, this commit adds back the pr_fmt(fmt) invocation, making net_dbg_ratelimited properly consistent across DEBUG, no DEBUG, and DYNAMIC_DEBUG cases, and bringing parity with the behavior of dynamic_pr_debug as well. Fixes: 2c94b5373 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case") Signed-off-by: Jason A. Donenfeld Cc: Tim Bingham Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit aae4204718b75dbafe5957a331ce4bc479285eb8 Author: WANG Cong Date: Mon Jun 13 13:44:14 2016 -0700 act_ipt: fix a bind refcnt leak [ Upstream commit d15eccea69b96a5116169688dcc9baf6d1ce2751 ] And avoid calling tcf_hash_check() twice. Fixes: a57f19d30b2d ("net sched: ipt action fix late binding") Cc: Jamal Hadi Salim Signed-off-by: Cong Wang Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6a23e18a677464b3e20fed580893efdfd018f80a Author: Eric Dumazet Date: Sun Jun 12 20:01:25 2016 -0700 net_sched: fix pfifo_head_drop behavior vs backlog [ Upstream commit 6c0d54f1897d229748d4f41ef919078db6db2123 ] When the qdisc is full, we drop a packet at the head of the queue, queue the current skb and return NET_XMIT_CN Now we track backlog on upper qdiscs, we need to call qdisc_tree_reduce_backlog(), even if the qlen did not change. Fixes: 2ccccf5fb43f ("net_sched: update hierarchical backlog too") Signed-off-by: Eric Dumazet Cc: WANG Cong Cc: Jamal Hadi Salim Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman