commit 0fd090c8b6c1f72165fc14bf2984508497a8ad10 Author: Jiri Slaby Date: Thu Apr 21 08:57:25 2016 +0200 Linux 3.12.59 commit e31a2100a342288b665c31af0a5f01e794866cda Author: Andrew Honig Date: Wed Nov 18 14:50:23 2015 -0800 KVM: x86: Reload pit counters for all channels when restoring state commit 0185604c2d82c560dab2f2933a18f797e74ab5a8 upstream. Currently if userspace restores the pit counters with a count of 0 on channels 1 or 2 and the guest attempts to read the count on those channels, then KVM will perform a mod of 0 and crash. This will ensure that 0 values are converted to 65536 as per the spec. This is CVE-2015-7513. Signed-off-by: Andy Honig Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 979e5410e280dee62e9942c7f5caca975815de10 Author: Saurabh Sengar Date: Fri Oct 30 12:56:11 2015 +0530 KVM: x86: removing unused variable commit 2da29bccc5045ea10c70cb3a69be777768fd0b66 upstream. removing unused variables, found by coccinelle Signed-off-by: Saurabh Sengar Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit afe5a791d374e50a06ada7f4eda4e921e1b77996 Author: Ryan Ware Date: Thu Feb 11 15:58:44 2016 -0800 EVM: Use crypto_memneq() for digest comparisons commit 613317bd212c585c20796c10afe5daaa95d4b0a1 upstream. This patch fixes vulnerability CVE-2016-2085. The problem exists because the vm_verify_hmac() function includes a use of memcmp(). Unfortunately, this allows timing side channel attacks; specifically a MAC forgery complexity drop from 2^128 to 2^12. This patch changes the memcmp() to the cryptographically safe crypto_memneq(). Reported-by: Xiaofei Rex Guo Signed-off-by: Ryan Ware Signed-off-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Jiri Slaby commit d68e944a8fcb2c6212b38064771c9f5af7b0b92c Author: James Yonan Date: Thu Sep 26 02:20:39 2013 -0600 crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks commit 6bf37e5aa90f18baf5acf4874bca505dd667c37f upstream. When comparing MAC hashes, AEAD authentication tags, or other hash values in the context of authentication or integrity checking, it is important not to leak timing information to a potential attacker, i.e. when communication happens over a network. Bytewise memory comparisons (such as memcmp) are usually optimized so that they return a nonzero value as soon as a mismatch is found. E.g, on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch and up to ~850 cyc for a full match (cold). This early-return behavior can leak timing information as a side channel, allowing an attacker to iteratively guess the correct result. This patch adds a new method crypto_memneq ("memory not equal to each other") to the crypto API that compares memory areas of the same length in roughly "constant time" (cache misses could change the timing, but since they don't reveal information about the content of the strings being compared, they are effectively benign). Iow, best and worst case behaviour take the same amount of time to complete (in contrast to memcmp). Note that crypto_memneq (unlike memcmp) can only be used to test for equality or inequality, NOT for lexicographical order. This, however, is not an issue for its use-cases within the crypto API. We tried to locate all of the places in the crypto API where memcmp was being used for authentication or integrity checking, and convert them over to crypto_memneq. crypto_memneq is declared noinline, placed in its own source file, and compiled with optimizations that might increase code size disabled ("Os") because a smart compiler (or LTO) might notice that the return value is always compared against zero/nonzero, and might then reintroduce the same early-return optimization that we are trying to avoid. Using #pragma or __attribute__ optimization annotations of the code for disabling optimization was avoided as it seems to be considered broken or unmaintained for long time in GCC [1]. Therefore, we work around that by specifying the compile flag for memneq.o directly in the Makefile. We found that this seems to be most appropriate. As we use ("Os"), this patch also provides a loop-free "fast-path" for frequently used 16 byte digests. Similarly to kernel library string functions, leave an option for future even further optimized architecture specific assembler implementations. This was a joint work of James Yonan and Daniel Borkmann. Also thanks for feedback from Florian Weimer on this and earlier proposals [2]. [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html [2] https://lkml.org/lkml/2013/2/10/131 Signed-off-by: James Yonan Signed-off-by: Daniel Borkmann Cc: Florian Weimer Signed-off-by: Herbert Xu Signed-off-by: Jiri Slaby commit 15216848e8c78335945cc19a4098bdd204baa99c Author: David Howells Date: Tue Nov 24 21:36:31 2015 +0000 KEYS: Fix handling of stored error in a negatively instantiated user key commit 096fe9eaea40a17e125569f9e657e34cdb6d73bd upstream. If a user key gets negatively instantiated, an error code is cached in the payload area. A negatively instantiated key may be then be positively instantiated by updating it with valid data. However, the ->update key type method must be aware that the error code may be there. The following may be used to trigger the bug in the user key type: keyctl request2 user user "" @u keyctl add user user "a" @u which manifests itself as: BUG: unable to handle kernel paging request at 00000000ffffff8a IP: [] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 PGD 7cc30067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000 RIP: 0010:[] [] __call_rcu.constprop.76+0x1f/0x280 [] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 RSP: 0018:ffff88003dd8bdb0 EFLAGS: 00010246 RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001 RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82 RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82 R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700 FS: 0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0 Stack: ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82 ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5 ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620 Call Trace: [] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136 [] user_update+0x8b/0xb0 security/keys/user_defined.c:129 [< inline >] __key_update security/keys/key.c:730 [] key_create_or_update+0x291/0x440 security/keys/key.c:908 [< inline >] SYSC_add_key security/keys/keyctl.c:125 [] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60 [] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185 Note the error code (-ENOKEY) in EDX. A similar bug can be tripped by: keyctl request2 trusted user "" @u keyctl add trusted user "a" @u This should also affect encrypted keys - but that has to be correctly parameterised or it will fail with EINVAL before getting to the bit that will crashes. Reported-by: Dmitry Vyukov Signed-off-by: David Howells Acked-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Jiri Slaby commit d26388bb266798547bb0314acc1b222119c1db93 Author: Eric W. Biederman Date: Tue Oct 7 16:22:52 2014 -0700 mnt: Move the clear of MNT_LOCKED from copy_tree to it's callers. commit 8486a7882b5ba906992fd78bbfcefaae7fe285cc upstream. Clear MNT_LOCKED in the callers of copy_tree except copy_mnt_ns, and collect_mounts. In copy_mnt_ns it is necessary to create an exact copy of a mount tree, so not clearing MNT_LOCKED is important. Similarly collect_mounts is used to take a snapshot of the mount tree for audit logging purposes and auditing using a faithful copy of the tree is important. This becomes particularly significant when we start setting MNT_LOCKED on rootfs to prevent it from being unmounted. Signed-off-by: "Eric W. Biederman" Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit cf9d5808b7a0e8c88cb3a5d198865567e08c03ea Author: Dmitry Monakhov Date: Thu Jan 23 15:55:21 2014 -0800 fs/pipe.c: skip file_update_time on frozen fs commit 7e775f46a125f894a1d71e96797c776dbec161f0 upstream. Pipe has no data associated with fs so it is not good idea to block pipe_write() if FS is frozen, but we can not update file's time on such filesystem. Let's use same idea as we use in touch_time(). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=65701 Signed-off-by: Dmitry Monakhov Reviewed-by: Jan Kara Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 3b86e790417645fa899ed658a8e17f6832cf3936 Author: Ignat Korchagin Date: Thu Mar 17 18:00:29 2016 +0000 USB: usbip: fix potential out-of-bounds write commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb upstream. Fix potential out-of-bounds write to urb->transfer_buffer usbip handles network communication directly in the kernel. When receiving a packet from its peer, usbip code parses headers according to protocol. As part of this parsing urb->actual_length is filled. Since the input for urb->actual_length comes from the network, it should be treated as untrusted. Any entity controlling the network may put any value in the input and the preallocated urb->transfer_buffer may not be large enough to hold the data. Thus, the malicious entity is able to write arbitrary data to kernel memory. Signed-off-by: Ignat Korchagin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 8bdb7e5ec74fd7314be5f8dd919fbd738fb8b431 Author: Florian Westphal Date: Tue Mar 22 18:02:50 2016 +0100 netfilter: x_tables: make sure e->next_offset covers remaining blob size commit 6e94e0cfb0887e4013b3b930fa6ab1fe6bb6ba91 upstream. Otherwise this function may read data beyond the ruleset blob. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Cc: Michal Kubecek Signed-off-by: Jiri Slaby commit 9192d640a3917d7daf313795b4b7fc6329b3f6e5 Author: Florian Westphal Date: Tue Mar 22 18:02:52 2016 +0100 netfilter: x_tables: fix unconditional helper commit 54d83fc74aa9ec72794373cb47432c5f7fb1a309 upstream. Ben Hawkes says: In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it is possible for a user-supplied ipt_entry structure to have a large next_offset field. This field is not bounds checked prior to writing a counter value at the supplied offset. Problem is that mark_source_chains should not have been called -- the rule doesn't have a next entry, so its supposed to return an absolute verdict of either ACCEPT or DROP. However, the function conditional() doesn't work as the name implies. It only checks that the rule is using wildcard address matching. However, an unconditional rule must also not be using any matches (no -m args). The underflow validator only checked the addresses, therefore passing the 'unconditional absolute verdict' test, while mark_source_chains also tested for presence of matches, and thus proceeeded to the next (not-existent) rule. Unify this so that all the callers have same idea of 'unconditional rule'. Reported-by: Ben Hawkes Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Jiri Slaby commit 099f87c4f3dae7c3816feb32a754fd9cf8cd4298 Author: Florian Westphal Date: Tue Mar 22 18:02:49 2016 +0100 netfilter: x_tables: validate e->target_offset early commit bdf533de6968e9686df777dc178486f600c6e617 upstream. We should check that e->target_offset is sane before mark_source_chains gets called since it will fetch the target entry for loop detection. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Acked-by: Michal Kubecek Signed-off-by: Jiri Slaby commit 2a032e307d35402306c6464537b8bc6a0a3ac91d Author: Willy Tarreau Date: Mon Jan 18 16:36:09 2016 +0100 pipe: limit the per-user amount of pages allocated in pipes commit 759c01142a5d0f364a462346168a56de28a80f52 upstream. On no-so-small systems, it is possible for a single process to cause an OOM condition by filling large pipes with data that are never read. A typical process filling 4000 pipes with 1 MB of data will use 4 GB of memory. On small systems it may be tricky to set the pipe max size to prevent this from happening. This patch makes it possible to enforce a per-user soft limit above which new pipes will be limited to a single page, effectively limiting them to 4 kB each, as well as a hard limit above which no new pipes may be created for this user. This has the effect of protecting the system against memory abuse without hurting other users, and still allowing pipes to work correctly though with less data at once. The limit are controlled by two new sysctls : pipe-user-pages-soft, and pipe-user-pages-hard. Both may be disabled by setting them to zero. The default soft limit allows the default number of FDs per process (1024) to create pipes of the default size (64kB), thus reaching a limit of 64MB before starting to create only smaller pipes. With 256 processes limited to 1024 FDs each, this results in 1024*64kB + (256*1024 - 1024) * 4kB = 1084 MB of memory allocated for a user. The hard limit is disabled by default to avoid breaking existing applications that make intensive use of pipes (eg: for splicing). Reported-by: socketpair@gmail.com Reported-by: Tetsuo Handa Mitigates: CVE-2013-4312 (Linux 2.0+) Suggested-by: Linus Torvalds Signed-off-by: Willy Tarreau Signed-off-by: Al Viro Signed-off-by: Jiri Slaby commit 62efb1f4b74c86bd27b28082228c46e31c98aeb7 Author: Chuck Lever Date: Wed Mar 12 12:51:30 2014 -0400 SUNRPC: Fix large reads on NFS/RDMA commit 2b7bbc963da8d076f263574af4138b5df2e1581f upstream. After commit a11a2bf4, "SUNRPC: Optimise away unnecessary data moves in xdr_align_pages", Thu Aug 2 13:21:43 2012, READs larger than a few hundred bytes via NFS/RDMA no longer work. This commit exposed a long-standing bug in rpcrdma_inline_fixup(). I reproduce this with an rsize=4096 mount using the cthon04 basic tests. Test 5 fails with an EIO error. For my reproducer, kernel log shows: NFS: server cheating in read reply: count 4096 > recvd 0 rpcrdma_inline_fixup() is zeroing the xdr_stream::page_len field, and xdr_align_pages() is now returning that value to the READ XDR decoder function. That field is set up by xdr_inline_pages() by the READ XDR encoder function. As far as I can tell, it is supposed to be left alone after that, as it describes the dimensions of the reply xdr_stream, not the contents of that stream. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68391 Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 9a2fa0d4c5b6427c76b6d6cb8587c2080a2add93 Author: Takashi Iwai Date: Tue Feb 2 14:14:10 2016 +0100 ALSA: timer: Sync timer deletion at closing the system timer commit f146357f069e71aff8e474c625bcebcd3094b3ab upstream. ALSA timer core framework has no sync point at stopping because it's called inside the spinlock. Thus we need a sync point at close for avoiding the stray timer task. This is simply done by implementing the close callback just calling del_timer_sync(). (It's harmless to call it unconditionally, as the core timer itself cares of the already deleted timer instance.) Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 6f6abe510fc7cb0f6933c1b99ab059b1899e9cdb Author: Romain Izard Date: Fri Jun 27 10:51:07 2014 +0200 mmc: Allow forward compatibility for eMMC commit 03a59437ef6b6ad7fb0165cb9b96c08d6bf057fc upstream. As stated by the eMMC 5.0 specification, a chip should not be rejected only because of the revision stated in the EXT_CSD_REV field of the EXT_CSD register. Remove the control on this value, the control of the CSD_STRUCTURE field should be sufficient to reject future incompatible changes. Signed-off-by: Romain Izard Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit 8bb06e0975c2587f5acd9f714c53130dd1fb5ca4 Author: Greg Thelen Date: Fri Nov 6 16:32:42 2015 -0800 fs, seqfile: always allow oom killer commit 0f930902eb8806cff8dcaef9ff9faf3cfa5fd748 upstream. Since 5cec38ac866b ("fs, seq_file: fallback to vmalloc instead of oom kill processes") seq_buf_alloc() avoids calling the oom killer for PAGE_SIZE or smaller allocations; but larger allocations can use the oom killer via vmalloc(). Thus reads of small files can return ENOMEM, but larger files use the oom killer to avoid ENOMEM. The effect of this bug is that reads from /proc and other virtual filesystems can return ENOMEM instead of the preferred behavior - oom killing something (possibly the calling process). I don't know of anyone except Google who has noticed the issue. I suspect the fix is more needed in smaller systems where there isn't any reclaimable memory. But these seem like the kinds of systems which probably don't use the oom killer for production situations. Memory overcommit requires use of the oom killer to select a victim regardless of file size. Enable oom killer for small seq_buf_alloc() allocations. Fixes: 5cec38ac866b ("fs, seq_file: fallback to vmalloc instead of oom kill processes") Signed-off-by: David Rientjes Signed-off-by: Greg Thelen Acked-by: Eric Dumazet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit ef2276fc46e695b72d0640dd9e154d3e244dc85b Author: David Rientjes Date: Fri Dec 12 16:56:16 2014 -0800 fs, seq_file: fallback to vmalloc instead of oom kill processes commit 5cec38ac866bfb8775638e71a86e4d8cac30caae upstream. Since commit 058504edd026 ("fs/seq_file: fallback to vmalloc allocation"), seq_buf_alloc() falls back to vmalloc() when the kmalloc() for contiguous memory fails. This was done to address order-4 slab allocations for reading /proc/stat on large machines and noticed because PAGE_ALLOC_COSTLY_ORDER < 4, so there is no infinite loop in the page allocator when allocating new slab for such high-order allocations. Contiguous memory isn't necessary for caller of seq_buf_alloc(), however. Other GFP_KERNEL high-order allocations that are <= PAGE_ALLOC_COSTLY_ORDER will simply loop forever in the page allocator and oom kill processes as a result. We don't want to kill processes so that we can allocate contiguous memory in situations when contiguous memory isn't necessary. This patch does the kmalloc() allocation with __GFP_NORETRY for high-order allocations. This still utilizes memory compaction and direct reclaim in the allocation path, the only difference is that it will fail immediately instead of oom kill processes when out of memory. [akpm@linux-foundation.org: add comment] Signed-off-by: David Rientjes Cc: Heiko Carstens Cc: Christoph Hellwig Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit f0592d355da50713a25c943a08142363237f1a41 Author: Bjørn Mork Date: Mon Mar 7 21:15:36 2016 +0100 cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind commit 4d06dd537f95683aba3651098ae288b7cbff8274 upstream. usbnet_link_change will call schedule_work and should be avoided if bind is failing. Otherwise we will end up with scheduled work referring to a netdev which has gone away. Instead of making the call conditional, we can just defer it to usbnet_probe, using the driver_info flag made for this purpose. Fixes: 8a34b0ae8778 ("usbnet: cdc_ncm: apply usbnet_link_change") Reported-by: Andrey Konovalov Suggested-by: Linus Torvalds Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9c186cff6026b5f54083647005b5247bfba0d43c Author: Bjørn Mork Date: Thu Dec 3 19:24:18 2015 +0100 net: qmi_wwan: MDM9x30 specific power management commit 93725149794d3d418cf1eddcae60c7b536c5faa1 upstream. MDM9x30 based modems appear to go into a deeper sleep when suspended without "Remote Wakeup" enabled. The QMI interface will not respond unless a "set DTR" control request is sent on resume. The effect is similar to a QMI_CTL SYNC request, resetting (some of) the firmware state. We allow userspace sessions to span multiple character device open/close sequences. This means that userspace can depend on firmware state while both the netdev and the character device are closed. We have disabled "needs_remote_wakeup" at this point to allow devices without remote wakeup support to be auto-suspended. To make sure the MDM9x30 keeps firmware state, we need to keep "needs_remote_wakeup" always set. We also need to issue a "set DTR" request to enable the QMI interface. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7d4647a410edf0b85529188ac364f365b5a3c7fb Author: Felipe F. Tonello Date: Wed Mar 9 19:39:30 2016 +0000 usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize commit 03d27ade4941076b34c823d63d91dc895731a595 upstream. buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed devices. That caused the OUT endpoint to freeze if the host send any data packet of length greater than 256 bytes. This is an example dump of what happended on that enpoint: HOST: [DATA][Length=260][...] DEVICE: [NAK] HOST: [PING] DEVICE: [NAK] HOST: [PING] DEVICE: [NAK] ... HOST: [PING] DEVICE: [NAK] This patch fixes this problem by setting the minimum usb_request's buffer size for the OUT endpoint as its wMaxPacketSize. Acked-by: Michal Nazarewicz Signed-off-by: Felipe F. Tonello Signed-off-by: Felipe Balbi Cc: Oliver Neukum Signed-off-by: Jiri Slaby commit d201f38e6a5823e7881310b7df6ace9e5d0319fe Author: Eryu Guan Date: Sat Mar 12 21:40:32 2016 -0500 ext4: fix NULL pointer dereference in ext4_mark_inode_dirty() commit 5e1021f2b6dff1a86a468a1424d59faae2bc63c1 upstream. ext4_reserve_inode_write() in ext4_mark_inode_dirty() could fail on error (e.g. EIO) and iloc.bh can be NULL in this case. But the error is ignored in the following "if" condition and ext4_expand_extra_isize() might be called with NULL iloc.bh set, which triggers NULL pointer dereference. This is uncovered by commit 8b4953e13f4c ("ext4: reserve code points for the project quota feature"), which enlarges the ext4_inode size, and run the following script on new kernel but with old mke2fs: #/bin/bash mnt=/mnt/ext4 devname=ext4-error dev=/dev/mapper/$devname fsimg=/home/fs.img trap cleanup 0 1 2 3 9 15 cleanup() { umount $mnt >/dev/null 2>&1 dmsetup remove $devname losetup -d $backend_dev rm -f $fsimg exit 0 } rm -f $fsimg fallocate -l 1g $fsimg backend_dev=`losetup -f --show $fsimg` devsize=`blockdev --getsz $backend_dev` good_tab="0 $devsize linear $backend_dev 0" error_tab="0 $devsize error $backend_dev 0" dmsetup create $devname --table "$good_tab" mkfs -t ext4 $dev mount -t ext4 -o errors=continue,strictatime $dev $mnt dmsetup load $devname --table "$error_tab" && dmsetup resume $devname echo 3 > /proc/sys/vm/drop_caches ls -l $mnt exit 0 [ Patch changed to simplify the function a tiny bit. -- Ted ] Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit 7cad2f73e038502abd444bfe22f3c03dbb6da610 Author: Guo-Fu Tseng Date: Sat Mar 5 08:11:56 2016 +0800 jme: Fix device PM wakeup API usage commit 81422e672f8181d7ad1ee6c60c723aac649f538f upstream. According to Documentation/power/devices.txt The driver should not use device_set_wakeup_enable() which is the policy for user to decide. Using device_init_wakeup() to initialize dev->power.should_wakeup and dev->power.can_wakeup on driver initialization. And use device_may_wakeup() on suspend to decide if WoL function should be enabled on NIC. Reported-by: Diego Viola Signed-off-by: Guo-Fu Tseng Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit f88511401a8ffeeadd72e7eaca02a6ede31248d3 Author: Guo-Fu Tseng Date: Sat Mar 5 08:11:55 2016 +0800 jme: Do not enable NIC WoL functions on S0 commit 0772a99b818079e628a1da122ac7ee023faed83e upstream. Otherwise it might be back on resume right after going to suspend in some hardware. Reported-by: Diego Viola Signed-off-by: Guo-Fu Tseng Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 5b166252bc3084f069bf8213ca5fa0861ccd44c4 Author: Vladis Dronov Date: Mon Nov 16 15:55:11 2015 -0200 usbvision: fix crash on detecting device with invalid configuration commit fa52bd506f274b7619955917abfde355e3d19ffe upstream. The usbvision driver crashes when a specially crafted usb device with invalid number of interfaces or endpoints is detected. This fix adds checks that the device has proper configuration expected by the driver. Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 4ae11c7f1bc611944effa70ab35b6f124360c3e3 Author: Alexey Khoroshilov Date: Fri Mar 27 19:39:09 2015 -0300 usbvision: fix leak of usb_dev on failure paths in usbvision_probe() commit afd270d1a45043cef14341bcceff62ed50e8dc9a upstream. There is no usb_put_dev() on failure paths in usbvision_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit e44488352da015c791d92a7a1d0e52443a229279 Author: Nicolai Hähnle Date: Tue Mar 15 12:56:45 2016 -0500 drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older) [Backport of upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb, with an additional NULL pointer guard that is required for kernels 3.17 and older. To be precise, any kernel that does *not* have commit 954605ca3 "drm/radeon: use common fence implementation for fences, v4" requires this additional NULL pointer guard.] An arbitrary amount of time can pass between spin_unlock and radeon_fence_wait_any, so we need to ensure that nobody frees the fences from under us. Based on the analogous fix for amdgpu. Signed-off-by: Nicolai Hähnle Reviewed-by: Christian König (v1 + fix) Tested-by: Lutz Euler Signed-off-by: Jiri Slaby commit 7db2180867d6c0761762b46b30185bbad9c9228a Author: Alan Stern Date: Wed Mar 23 12:17:09 2016 -0400 HID: usbhid: fix inconsistent reset/resume/reset-resume behavior commit 972e6a993f278b416a8ee3ec65475724fc36feb2 upstream. The usbhid driver has inconsistently duplicated code in its post-reset, resume, and reset-resume pathways. reset-resume doesn't check HID_STARTED before trying to restart the I/O queues. resume fails to clear the HID_SUSPENDED flag if HID_STARTED isn't set. resume calls usbhid_restart_queues() with usbhid->lock held and the others call it without holding the lock. The first item in particular causes a problem following a reset-resume if the driver hasn't started up its I/O. URB submission fails because usbhid->urbin is NULL, and this triggers an unending reset-retry loop. This patch fixes the problem by creating a new subroutine, hid_restart_io(), to carry out all the common activities. It also adds some checks that were missing in the original code: After a reset, there's no need to clear any halted endpoints. After a resume, if a reset is pending there's no need to restart any I/O until the reset is finished. After a resume, if the interrupt-IN endpoint is halted there's no need to submit the input URB until the halt has been cleared. Signed-off-by: Alan Stern Reported-by: Daniel Fraga Tested-by: Daniel Fraga Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby commit 3ea8a50be86da7690db5fd03ae3a3911773164ec Author: Peter Zijlstra Date: Wed Feb 24 18:45:46 2016 +0100 perf: Cure event->pending_disable race commit 28a967c3a2f99fa3b5f762f25cb2a319d933571b upstream. Because event_sched_out() checks event->pending_disable _before_ actually disabling the event, it can happen that the event fires after it checks but before it gets disabled. This would leave event->pending_disable set and the queued irq_work will try and process it. However, if the event trigger was during schedule(), the event might have been de-scheduled by the time the irq_work runs, and perf_event_disable_local() will fail. Fix this by checking event->pending_disable _after_ we call event->pmu->del(). This depends on the latter being a compiler barrier, such that the compiler does not lift the load and re-creates the problem. Tested-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dvyukov@google.com Cc: eranian@google.com Cc: oleg@redhat.com Cc: panand@redhat.com Cc: sasha.levin@oracle.com Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160224174948.040469884@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit b44d9f302fab3f40535be53f0b7ec5cfa8386643 Author: Theodore Ts'o Date: Fri Apr 1 01:31:28 2016 -0400 ext4: add lockdep annotations for i_data_sem commit daf647d2dd58cec59570d7698a45b98e580f2076 upstream. With the internal Quota feature, mke2fs creates empty quota inodes and quota usage tracking is enabled as soon as the file system is mounted. Since quotacheck is no longer preallocating all of the blocks in the quota inode that are likely needed to be written to, we are now seeing a lockdep false positive caused by needing to allocate a quota block from inside ext4_map_blocks(), while holding i_data_sem for a data inode. This results in this complaint: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ei->i_data_sem); lock(&s->s_dquot.dqio_mutex); lock(&ei->i_data_sem); lock(&s->s_dquot.dqio_mutex); Google-Bug-Id: 27907753 Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit 070a20e7d682b49b8dac8b482d7a249d0db506d0 Author: Yoshihiro Shimoda Date: Thu Mar 10 11:30:15 2016 +0900 usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer commit 6490865c67825277b29638e839850882600b48ec upstream. This patch adds a code to surely disable TX IRQ of the pipe before starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs may happen in rare cases when DMAC is used. Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit a24024751513da40e7c830cb2e50ed35c2fb4a9b Author: Yoshihiro Shimoda Date: Thu Mar 10 11:30:14 2016 +0900 usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() commit 894f2fc44f2f3f48c36c973b1123f6ab298be160 upstream. When unexpected situation happened (e.g. tx/rx irq happened while DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL pointer dereference like the followings: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 80000007 [#1] SMP ARM Modules linked in: usb_f_acm u_serial g_serial libcomposite CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63 Hardware name: Generic R8A7790 (Flattened Device Tree) task: c0729c00 ti: c0724000 task.ti: c0724000 PC is at 0x0 LR is at usbhsf_pkt_handler+0xac/0x118 pc : [<00000000>] lr : [] psr: 60000193 sp : c0725db8 ip : 00000000 fp : c0725df4 r10: 00000001 r9 : 00000193 r8 : ef3ccab4 r7 : ef3cca10 r6 : eea4586c r5 : 00000000 r4 : ef19ceb4 r3 : 00000000 r2 : 0000009c r1 : c0725dc4 r0 : ef19ceb4 This patch adds a condition to avoid the dereference. Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit a566941a4a3d88ec8235f7cc56902558d40e7042 Author: Michal Kazior Date: Mon Jan 25 14:43:24 2016 +0100 mac80211: fix unnecessary frame drops in mesh fwding commit cf44012810ccdd8fd947518e965cb04b7b8498be upstream. The ieee80211_queue_stopped() expects hw queue number but it was given raw WMM AC number instead. This could cause frame drops and problems with traffic in some cases - most notably if driver doesn't map AC numbers to queue numbers 1:1 and uses ieee80211_stop_queues() and ieee80211_wake_queue() only without ever calling ieee80211_wake_queues(). On ath10k it was possible to hit this problem in the following case: 1. wlan0 uses queue 0 (ath10k maps queues per vif) 2. offchannel uses queue 15 3. queues 1-14 are unused 4. ieee80211_stop_queues() 5. ieee80211_wake_queue(q=0) 6. ieee80211_wake_queue(q=15) (other queues are not woken up because both driver and mac80211 know other queues are unused) 7. ieee80211_rx_h_mesh_fwding() 8. ieee80211_select_queue_80211() returns 2 9. ieee80211_queue_stopped(q=2) returns true 10. frame is dropped (oops!) Fixes: d3c1597b8d1b ("mac80211: fix forwarded mesh frame queue mapping") Signed-off-by: Michal Kazior Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit bc2d8a1f629272916b402b40d54bd3ac4c0c6595 Author: Boris Ostrovsky Date: Fri Mar 18 10:11:07 2016 -0400 xen/events: Mask a moving irq commit ff1e22e7a638a0782f54f81a6c9cb139aca2da35 upstream. Moving an unmasked irq may result in irq handler being invoked on both source and target CPUs. With 2-level this can happen as follows: On source CPU: evtchn_2l_handle_events() -> generic_handle_irq() -> handle_edge_irq() -> eoi_pirq(): irq_move_irq(data); /***** WE ARE HERE *****/ if (VALID_EVTCHN(evtchn)) clear_evtchn(evtchn); If at this moment target processor is handling an unrelated event in evtchn_2l_handle_events()'s loop it may pick up our event since target's cpu_evtchn_mask claims that this event belongs to it *and* the event is unmasked and still pending. At the same time, source CPU will continue executing its own handle_edge_irq(). With FIFO interrupt the scenario is similar: irq_move_irq() may result in a EVTCHNOP_unmask hypercall which, in turn, may make the event pending on the target CPU. We can avoid this situation by moving and clearing the event while keeping event masked. Signed-off-by: Boris Ostrovsky Signed-off-by: David Vrabel Signed-off-by: Jiri Slaby commit a3e63f3aff2762aa9ee0d6e0101584ca39abc9c7 Author: Wei Liu Date: Thu Mar 7 15:50:27 2013 +0000 xen/events: introduce test_and_set_mask() commit 3f70fa828249e3f37883be98f5b4d08e947f55b0 upstream. In preparation for adding event channel port ops, add test_and_set_mask(). Signed-off-by: Wei Liu Signed-off-by: David Vrabel Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Boris Ostrovsky Signed-off-by: Jiri Slaby commit a668a8394cc07e3e65f07a2039d38663cee83d1e Author: Alex Deucher Date: Mon Mar 28 10:21:20 2016 -0400 drm/radeon: add a dpm quirk for all R7 370 parts commit 0e5585dc870af947fab2af96a88c2d8b4270247c upstream. Higher mclk values are not stable due to a bug somewhere. Limit them for now. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 7562a6db8b2eaf50a9262c99144805344cea7869 Author: Alex Deucher Date: Fri Mar 25 10:31:04 2016 -0400 drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5 commit f971f2263deaa4a441e377b385c11aee0f3b3f9a upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=94692 Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 8fd077773ca78811c68c7a537cf21761da5046fc Author: Xishi Qiu Date: Fri Apr 1 14:31:20 2016 -0700 mm: fix invalid node in alloc_migrate_target() commit 6f25a14a7053b69917e2ebea0d31dd444cd31fd5 upstream. It is incorrect to use next_node to find a target node, it will return MAX_NUMNODES or invalid node. This will lead to crash in buddy system allocation. Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage") Signed-off-by: Xishi Qiu Acked-by: Vlastimil Babka Acked-by: Naoya Horiguchi Cc: Joonsoo Kim Cc: David Rientjes Cc: "Laura Abbott" Cc: Hui Zhu Cc: Wang Xiaoqiang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 415ab75664a7aa63fe8520e9500f6759f01a3daf Author: Takashi Iwai Date: Fri Apr 1 12:28:16 2016 +0200 ALSA: timer: Use mod_timer() for rearming the system timer commit 4a07083ed613644c96c34a7dd2853dc5d7c70902 upstream. ALSA system timer backend stops the timer via del_timer() without sync and leaves del_timer_sync() at the close instead. This is because of the restriction by the design of ALSA timer: namely, the stop callback may be called from the timer handler, and calling the sync shall lead to a hangup. However, this also triggers a kernel BUG() when the timer is rearmed immediately after stopping without sync: kernel BUG at kernel/time/timer.c:966! Call Trace: [] snd_timer_s_start+0x13e/0x1a0 [] snd_timer_interrupt+0x504/0xec0 [] ? debug_check_no_locks_freed+0x290/0x290 [] snd_timer_s_function+0xb4/0x120 [] call_timer_fn+0x162/0x520 [] ? call_timer_fn+0xcd/0x520 [] ? snd_timer_interrupt+0xec0/0xec0 .... It's the place where add_timer() checks the pending timer. It's clear that this may happen after the immediate restart without sync in our cases. So, the workaround here is just to use mod_timer() instead of add_timer(). This looks like a band-aid fix, but it's a right move, as snd_timer_interrupt() takes care of the continuous rearm of timer. Reported-by: Jiri Slaby Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 168d26de82bf018acec1768ddf1f818e434d00be Author: Helge Deller Date: Fri Apr 8 18:18:48 2016 +0200 parisc: Fix kernel crash with reversed copy_from_user() commit ef72f3110d8b19f4c098a0bff7ed7d11945e70c6 upstream. The kernel module testcase (lib/test_user_copy.c) exhibited a kernel crash on parisc if the parameters for copy_from_user were reversed ("illegal reversed copy_to_user" testcase). Fix this potential crash by checking the fault handler if the faulting address is in the exception table. Signed-off-by: Helge Deller Cc: Kees Cook Signed-off-by: Jiri Slaby commit b13667443e6ccdec329773cc70bb5962d62c159d Author: Helge Deller Date: Fri Apr 8 18:11:33 2016 +0200 parisc: Avoid function pointers for kernel exception routines commit e3893027a300927049efc1572f852201eb785142 upstream. We want to avoid the kernel module loader to create function pointers for the kernel fixup routines of get_user() and put_user(). Changing the external reference from function type to int type fixes this. This unbreaks exception handling for get_user() and put_user() when called from a kernel module. Signed-off-by: Helge Deller Signed-off-by: Jiri Slaby commit f51d4ce2146ca0d66a0d623d4a0b2e4d86faedff Author: Guenter Roeck Date: Sat Mar 26 12:28:05 2016 -0700 hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated commit 3c2e2266a5bd2d1cef258e6e54dca1d99946379f upstream. arm:pxa_defconfig can result in the following crash if the max1111 driver is not instantiated. Unhandled fault: page domain fault (0x01b) at 0x00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: : 1b [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680407c #10 Hardware name: SHARP Akita Workqueue: events sharpsl_charge_toggle task: c390a000 ti: c391e000 task.ti: c391e000 PC is at max1111_read_channel+0x20/0x30 LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c pc : [] lr : [] psr: 20000013 ... [] (max1111_read_channel) from [] (sharpsl_pm_pxa_read_max1111+0x2c/0x3c) [] (sharpsl_pm_pxa_read_max1111) from [] (spitzpm_read_devdata+0x5c/0xc4) [] (spitzpm_read_devdata) from [] (sharpsl_check_battery_temp+0x78/0x110) [] (sharpsl_check_battery_temp) from [] (sharpsl_charge_toggle+0x48/0x110) [] (sharpsl_charge_toggle) from [] (process_one_work+0x14c/0x48c) [] (process_one_work) from [] (worker_thread+0x3c/0x5d4) [] (worker_thread) from [] (kthread+0xd0/0xec) [] (kthread) from [] (ret_from_fork+0x14/0x24) This can occur because the SPI controller driver (SPI_PXA2XX) is built as module and thus not necessarily loaded. While building SPI_PXA2XX into the kernel would make the problem disappear, it appears prudent to ensure that the driver is instantiated before accessing its data structures. Cc: Arnd Bergmann Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit 28a9b9b7931f5e79d94e2a3169feff1957c3a98f Author: Petr Štetiar Date: Thu Nov 5 12:55:01 2015 +0100 USB: qmi_wwan: Add quirk for Quectel EC20 Mini PCIe module commit b3d8cf019fb9dd28389b08da7bf54ffabf453ed3 upstream. This device has same vendor and product IDs as G2K devices, but it has different number of interfaces(4 vs 5) and also different interface layout where EC20 has QMI on interface 4 instead of 0. lsusb output: Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x05c6 Qualcomm, Inc. idProduct 0x9215 Acer Gobi 2000 Wireless Modem bcdDevice 2.32 iManufacturer 1 Quectel iProduct 2 Quectel LTE Module iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 209 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Signed-off-by: Petr Štetiar Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9dfcd3a8f55ce1d77cc34298100655cc214b83f5 Author: Jakub Sitnicki Date: Tue Apr 5 18:41:08 2016 +0200 ipv6: Count in extension headers in skb->network_header [ Upstream commit 3ba3458fb9c050718b95275a3310b74415e767e2 ] When sending a UDPv6 message longer than MTU, account for the length of fragmentable IPv6 extension headers in skb->network_header offset. Same as we do in alloc_new_skb path in __ip6_append_data(). This ensures that later on __ip6_make_skb() will make space in headroom for fragmentable extension headers: /* move skb->data to ip header from ext header */ if (skb->data < skb_network_header(skb)) __skb_pull(skb, skb_network_offset(skb)); Prevents a splat due to skb_under_panic: skbuff: skb_under_panic: text:ffffffff8143397b len:2126 put:14 \ head:ffff880005bacf50 data:ffff880005bacf4a tail:0x48 end:0xc0 dev:lo ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:104! invalid opcode: 0000 [#1] KASAN CPU: 0 PID: 160 Comm: reproducer Not tainted 4.6.0-rc2 #65 [...] Call Trace: [] skb_push+0x79/0x80 [] eth_header+0x2b/0x100 [] neigh_resolve_output+0x210/0x310 [] ip6_finish_output2+0x4a7/0x7c0 [] ip6_output+0x16a/0x280 [] ip6_local_out+0xb1/0xf0 [] ip6_send_skb+0x45/0xd0 [] udp_v6_send_skb+0x246/0x5d0 [] udpv6_sendmsg+0xa6e/0x1090 [...] Reported-by: Ji Jianwen Signed-off-by: Jakub Sitnicki Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 4eb6e92eea61e52d4c0239ccd1fb9afa8fb0659b Author: Thadeu Lima de Souza Cascardo Date: Fri Apr 1 17:17:50 2016 -0300 ip6_tunnel: set rtnl_link_ops before calling register_netdevice [ Upstream commit b6ee376cb0b7fb4e7e07d6cd248bd40436fb9ba6 ] When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set before ip6_tnl_create2 is called. When register_netdevice is called, there is no linkinfo attribute in the NEWLINK message because of that. Setting rtnl_link_ops before calling register_netdevice fixes that. Fixes: 0b112457229d ("ip6tnl: add support of link creation via rtnl") Signed-off-by: Thadeu Lima de Souza Cascardo Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 80136dc21d389e0213f173a3a7a00c8d95f75c21 Author: Haishuang Yan Date: Sun Apr 3 22:09:24 2016 +0800 ipv6: l2tp: fix a potential issue in l2tp_ip6_recv [ Upstream commit be447f305494e019dfc37ea4cdf3b0e4200b4eba ] pskb_may_pull() can change skb->data, so we have to load ptr/optr at the right place. Signed-off-by: Haishuang Yan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 4a05fe250a8195d5568d91e926b0800eca9e35f2 Author: Haishuang Yan Date: Sun Apr 3 22:09:23 2016 +0800 ipv4: l2tp: fix a potential issue in l2tp_ip_recv [ Upstream commit 5745b8232e942abd5e16e85fa9b27cc21324acf0 ] pskb_may_pull() can change skb->data, so we have to load ptr/optr at the right place. Signed-off-by: Haishuang Yan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e1e03d36ca1eb563b11827760a5e5a5d74377f37 Author: subashab@codeaurora.org Date: Wed Mar 23 22:39:50 2016 -0600 xfrm: Fix crash observed during device unregistration and decryption [ Upstream commit 071d36bf21bcc837be00cea55bcef8d129e7f609 ] A crash is observed when a decrypted packet is processed in receive path. get_rps_cpus() tries to dereference the skb->dev fields but it appears that the device is freed from the poison pattern. [] get_rps_cpu+0x94/0x2f0 [] netif_rx_internal+0x140/0x1cc [] netif_rx+0x74/0x94 [] xfrm_input+0x754/0x7d0 [] xfrm_input_resume+0x10/0x1c [] esp_input_done+0x20/0x30 [] process_one_work+0x244/0x3fc [] worker_thread+0x2f8/0x418 [] kthread+0xe0/0xec -013|get_rps_cpu( | dev = 0xFFFFFFC08B688000, | skb = 0xFFFFFFC0C76AAC00 -> ( | dev = 0xFFFFFFC08B688000 -> ( | name = "...................................................... | name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev = 0xAAAAAAAAAAA Following are the sequence of events observed - - Encrypted packet in receive path from netdevice is queued - Encrypted packet queued for decryption (asynchronous) - Netdevice brought down and freed - Packet is decrypted and returned through callback in esp_input_done - Packet is queued again for process in network stack using netif_rx Since the device appears to have been freed, the dereference of skb->dev in get_rps_cpus() leads to an unhandled page fault exception. Fix this by holding on to device reference when queueing packets asynchronously and releasing the reference on call back return. v2: Make the change generic to xfrm as mentioned by Steffen and update the title to xfrm Suggested-by: Herbert Xu Signed-off-by: Jerome Stanislaus Signed-off-by: Subash Abhinov Kasiviswanathan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 736a17fe375978bce54cff359a3f76fb2676f872 Author: Guillaume Nault Date: Wed Mar 23 16:38:55 2016 +0100 ppp: take reference on channels netns [ Upstream commit 1f461dcdd296eecedaffffc6bae2bfa90bd7eb89 ] Let channels hold a reference on their network namespace. Some channel types, like ppp_async and ppp_synctty, can have their userspace controller running in a different namespace. Therefore they can't rely on them to preclude their netns from being removed from under them. ================================================================== BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at addr ffff880064e217e0 Read of size 8 by task syz-executor/11581 ============================================================================= BUG net_namespace (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906 [< none >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440 [< none >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469 [< inline >] slab_alloc_node kernel/mm/slub.c:2532 [< inline >] slab_alloc kernel/mm/slub.c:2574 [< none >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579 [< inline >] kmem_cache_zalloc kernel/include/linux/slab.h:597 [< inline >] net_alloc kernel/net/core/net_namespace.c:325 [< none >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360 [< none >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95 [< none >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150 [< none >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451 [< inline >] copy_process kernel/kernel/fork.c:1274 [< none >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723 [< inline >] SYSC_clone kernel/kernel/fork.c:1832 [< none >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826 [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185 INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631 [< none >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650 [< inline >] slab_free kernel/mm/slub.c:2805 [< none >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814 [< inline >] net_free kernel/net/core/net_namespace.c:341 [< none >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348 [< none >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448 [< none >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036 [< none >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170 [< none >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303 [< none >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468 INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000 flags=0x5fffc0000004080 INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200 CPU: 1 PID: 11581 Comm: syz-executor Tainted: G B 4.4.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300 ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054 ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000 Call Trace: [< inline >] __dump_stack kernel/lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50 [] print_trailer+0xf4/0x150 kernel/mm/slub.c:654 [] object_err+0x2f/0x40 kernel/mm/slub.c:661 [< inline >] print_address_description kernel/mm/kasan/report.c:138 [] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236 [< inline >] kasan_report kernel/mm/kasan/report.c:259 [] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280 [< inline >] ? ppp_pernet kernel/include/linux/compiler.h:218 [] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [< inline >] ppp_pernet kernel/include/linux/compiler.h:218 [] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [< inline >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293 [] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241 [] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000 [] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478 [] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744 [] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772 [] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901 [] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688 [] __fput+0x236/0x780 kernel/fs/file_table.c:208 [] ____fput+0x15/0x20 kernel/fs/file_table.c:244 [] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115 [< inline >] exit_task_work kernel/include/linux/task_work.h:21 [] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750 [] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123 [] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357 [] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550 [] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145 [] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880 [] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307 [< inline >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113 [] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158 [] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712 [] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655 [] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165 [] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692 [< inline >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099 [] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678 [< inline >] ? context_switch kernel/kernel/sched/core.c:2807 [] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283 [] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247 [< inline >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282 [] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344 [] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281 Memory state around the buggy address: ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2") Reported-by: Baozeng Ding Signed-off-by: Guillaume Nault Reviewed-by: Cyrill Gorcunov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit ee9f959bc71defafb934800903c12f192ba561f2 Author: Manish Chopra Date: Tue Mar 15 07:13:45 2016 -0400 qlge: Fix receive packets drop. [ Upstream commit 2c9a266afefe137bff06bbe0fc48b4d3b3cb348c ] When running small packets [length < 256 bytes] traffic, packets were being dropped due to invalid data in those packets which were delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu ensures copying latest and updated data into skb from the receive buffer. Signed-off-by: Sony Chacko Signed-off-by: Manish Chopra Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 46e63be265a21151fe4acb4f46fd5274ce7694eb Author: Dmitri Epshtein Date: Sat Mar 12 18:44:18 2016 +0100 net: mvneta: enable change MAC address when interface is up [ Upstream commit 928b6519afeb2a5e2dc61154380b545ed66c476a ] Function eth_prepare_mac_addr_change() is called as part of MAC address change. This function check if interface is running. To enable change MAC address when interface is running: IFF_LIVE_ADDR_CHANGE flag must be set to dev->priv_flags field Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit") Cc: stable@vger.kernel.org Signed-off-by: Dmitri Epshtein Signed-off-by: Gregory CLEMENT Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 13ee1c28f6a223def7a032865f216906101c0c38 Author: Arnd Bergmann Date: Mon Mar 14 15:18:36 2016 +0100 ath9k: fix buffer overrun for ar9287 [ Upstream commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5 ] Code that was added back in 2.6.38 has an obvious overflow when accessing a static array, and at the time it was added only a code comment was put in front of it as a reminder to have it reviewed properly. This has not happened, but gcc-6 now points to the specific overflow: drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs': drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds] maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4]; ~~~~~~~~~~~~~~~~~~~~~~~~~^~~ It turns out that the correct array length exists in the local 'intercepts' variable of this function, so we can just use that instead of hardcoding '4', so this patch changes all three instances to use that variable. The other two instances were already correct, but it's more consistent this way. Signed-off-by: Arnd Bergmann Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs") Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 217dc642bde02aafbda9d0d107c10d0e6f9684bc Author: Arnd Bergmann Date: Mon Mar 14 15:18:35 2016 +0100 farsync: fix off-by-one bug in fst_add_one [ Upstream commit e725a66c0202b5f36c2f9d59d26a65c53bbf21f7 ] gcc-6 finds an out of bounds access in the fst_add_one function when calculating the end of the mmio area: drivers/net/wan/farsync.c: In function 'fst_add_one': drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds] #define BUF_OFFSET(X) (BFM_BASE + offsetof(struct buf_window, X)) ^ include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof' __builtin_offsetof(a, b) ^ drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof' #define BUF_OFFSET(X) (BFM_BASE + offsetof(struct buf_window, X)) ^~~~~~~~ drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET' + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]); ^~~~~~~~~~ The warning is correct, but not critical because this appears to be a write-only variable that is set by each WAN driver but never accessed afterwards. I'm taking the minimal fix here, using the correct pointer by pointing 'mem_end' to the last byte inside of the register area as all other WAN drivers do, rather than the first byte outside of it. An alternative would be to just remove the mem_end member entirely. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e58dc03502eb6dd40f41c1a5466756dc8435202f Author: Arnd Bergmann Date: Mon Mar 14 15:18:34 2016 +0100 mlx4: add missing braces in verify_qp_parameters [ Upstream commit baefd7015cdb304ce6c94f9679d0486c71954766 ] The implementation of QP paravirtualization back in linux-3.7 included some code that looks very dubious, and gcc-6 has grown smart enough to warn about it: drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'verify_qp_parameters': drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3154:5: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] if (optpar & MLX4_QP_OPTPAR_ALT_ADDR_PATH) { ^~ drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3144:4: note: ...this 'if' clause, but it is not if (slave != mlx4_master_func_num(dev)) >From looking at the context, I'm reasonably sure that the indentation is correct but that it should have contained curly braces from the start, as the update_gid() function in the same patch correctly does. Signed-off-by: Arnd Bergmann Fixes: 54679e148287 ("mlx4: Implement QP paravirtualization and maintain phys_pkey_cache for smp_snoop") Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 2c7a8d368b3bef1cf97ea000ba0c07b27562af15 Author: Arnaldo Carvalho de Melo Date: Mon Mar 14 09:56:35 2016 -0300 net: Fix use after free in the recvmmsg exit path [ Upstream commit 34b88a68f26a75e4fded796f1a49c40f82234b7d ] The syzkaller fuzzer hit the following use-after-free: Call Trace: [] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295 [] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261 [< inline >] SYSC_recvmmsg net/socket.c:2281 [] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 And, as Dmitry rightly assessed, that is because we can drop the reference and then touch it when the underlying recvmsg calls return some packets and then hit an error, which will make recvmmsg to set sock->sk->sk_err, oops, fix it. Reported-and-Tested-by: Dmitry Vyukov Cc: Alexander Potapenko Cc: Eric Dumazet Cc: Kostya Serebryany Cc: Sasha Levin Fixes: a2e2725541fa ("net: Introduce recvmmsg socket syscall") http://lkml.kernel.org/r/20160122211644.GC2470@redhat.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7b0c14e2b54027548f1479e2617cacceea6d378c Author: Willem de Bruijn Date: Tue Mar 8 15:18:54 2016 -0500 macvtap: always pass ethernet header in linear [ Upstream commit 8e2ad4113ce4671686740f808ff2795395c39eef ] The stack expects link layer headers in the skb linear section. Macvtap can create skbs with llheader in frags in edge cases: when (IFF_VNET_HDR is off or vnet_hdr.hdr_len < ETH_HLEN) and prepad + len > PAGE_SIZE and vnet_hdr.flags has no or bad csum. Add checks to ensure linear is always at least ETH_HLEN. At this point, len is already ensured to be >= ETH_HLEN. For backwards compatiblity, rounds up short vnet_hdr.hdr_len. This differs from tap and packet, which return an error. Fixes b9fb9ee07e67 ("macvtap: add GSO/csum offload support") Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit f36a1644e067981263fe82a1eb2c13069c60fa5d Author: Sergei Shtylyov Date: Tue Mar 8 01:36:28 2016 +0300 sh_eth: fix NULL pointer dereference in sh_eth_ring_format() [ Upstream commit c1b7fca65070bfadca94dd53a4e6b71cd4f69715 ] In a low memory situation, if netdev_alloc_skb() fails on a first RX ring loop iteration in sh_eth_ring_format(), 'rxdesc' is still NULL. Avoid kernel oops by adding the 'rxdesc' check after the loop. Reported-by: Wolfram Sang Signed-off-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 64a08e78fa83406a1a9bace07f8de6b104af2068 Author: Bill Sommerfeld Date: Fri Mar 4 14:47:21 2016 -0800 udp6: fix UDP/IPv6 encap resubmit path [ Upstream commit 59dca1d8a6725a121dae6c452de0b2611d5865dc ] IPv4 interprets a negative return value from a protocol handler as a request to redispatch to a new protocol. In contrast, IPv6 interprets a negative value as an error, and interprets a positive value as a request for redispatch. UDP for IPv6 was unaware of this difference. Change __udp6_lib_rcv() to return a positive value for redispatch. Note that the socket's encap_rcv hook still needs to return a negative value to request dispatch, and in the case of IPv6 packets, adjust IP6CB(skb)->nhoff to identify the byte containing the next protocol. Signed-off-by: Bill Sommerfeld Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1f001b6a11b79a0518db5121abb0699b2d09ed6c Author: Oliver Neukum Date: Mon Mar 7 11:31:10 2016 +0100 usbnet: cleanup after bind() in probe() [ Upstream commit 1666984c8625b3db19a9abc298931d35ab7bc64b ] In case bind() works, but a later error forces bailing in probe() in error cases work and a timer may be scheduled. They must be killed. This fixes an error case related to the double free reported in http://www.spinics.net/lists/netdev/msg367669.html and needs to go on top of Linus' fix to cdc-ncm. Signed-off-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 88a61dbb3b73acb7dcd5317bd5c8283077f55cbb Author: Bjørn Mork Date: Thu Mar 3 22:20:53 2016 +0100 cdc_ncm: toggle altsetting to force reset before setup [ Upstream commit 48906f62c96cc2cd35753e59310cb70eb08cc6a5 ] Some devices will silently fail setup unless they are reset first. This is necessary even if the data interface is already in altsetting 0, which it will be when the device is probed for the first time. Briefly toggling the altsetting forces a function reset regardless of the initial state. This fixes a setup problem observed on a number of Huawei devices, appearing to operate in NTB-32 mode even if we explicitly set them to NTB-16 mode. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c2f68b2e2e01b6a4081bee02e0c6646d5f7e83b4 Author: Florian Westphal Date: Tue Mar 1 16:15:16 2016 +0100 ipv6: re-enable fragment header matching in ipv6_find_hdr [ Upstream commit 5d150a985520bbe3cb2aa1ceef24a7e32f20c15f ] When ipv6_find_hdr is used to find a fragment header (caller specifies target NEXTHDR_FRAGMENT) we erronously return -ENOENT for all fragments with nonzero offset. Before commit 9195bb8e381d, when target was specified, we did not enter the exthdr walk loop as nexthdr == target so this used to work. Now we do (so we can skip empty route headers). When we then stumble upon a frag with nonzero frag_off we must return -ENOENT ("header not found") only if the caller did not specifically request NEXTHDR_FRAGMENT. This allows nfables exthdr expression to match ipv6 fragments, e.g. via nft add rule ip6 filter input frag frag-off gt 0 Fixes: 9195bb8e381d ("ipv6: improve ipv6_find_hdr() to skip empty routing headers") Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit be212a56698c9918e5262974713505b7cdd5c171 Author: Yegor Yefremov Date: Fri Mar 28 12:07:18 2014 +0100 qmi_wwan/cdc_ether: move Novatel E371 (1410:9011) to qmi_wwan commit 7b5939ba591e9affbe4f336935b0985fd250a2b3 upstream. This device provides QMI and ethernet functionality via a standard CDC ethernet descriptor. But when driven by cdc_ether, the QMI functionality is unavailable because only cdc_ether can claim the USB interface. Thus blacklist the device in cdc_ether and add its IDs to qmi_wwan, which enables both QMI and ethernet simultaneously. Signed-off-by: Yegor Yefremov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 01ddadf4b8ac1e82c3ed82e6c49c02414f0360ee Author: Schemmel Hans-Christoph Date: Thu Mar 17 10:07:56 2016 +0000 qmi_wwan: Added support for Gemalto's Cinterion PHxx WWAN interface commit bd9e33508c5e1eb5d807d11d7bfc52125fcdb04e upstream. Added support for Gemalto's Cinterion PHxx WWAN interfaces by adding QMI_FIXED_INTF with Cinterion's VID and PID. PHxx can have: 2 RmNet Interfaces (PID 0x0082) or 1 RmNet + 1 USB Audio interface (PID 0x0083). Signed-off-by: Hans-Christoph Schemmel Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit a0426acdb70c91318c001504d8481aa2a147dc17 Author: Bjørn Mork Date: Tue Mar 1 14:31:02 2016 +0100 qmi_wwan: add Sierra Wireless EM74xx device ID commit bf13c94ccb33c3182efc92ce4989506a0f541243 upstream. The MC74xx and EM74xx modules use different IDs by default, according to the Lenovo EM7455 driver for Windows. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9ffe0a7a94f75b00162165d5d0cb5dbd10e3b0f8 Author: Patrik Halfar Date: Sat Feb 20 18:49:40 2016 +0100 Add Dell Wireless 5809e Gobi 4G HSPA+ Mobile Broadband Card (rev3) to qmi_wwan commit fb5eb24cdd5cdb83be77d3e4b2f16e92e06bd9e9 upstream. New revison of Dell Wireless 5809e Gobi 4G HSPA+ Mobile Broadband Card has new idProduct Bus 002 Device 006: ID 413c:81b3 Dell Computer Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x413c Dell Computer Corp. idProduct 0x81b3 bcdDevice 0.06 iManufacturer 1 Sierra Wireless, Incorporated iProduct 2 Dell Wireless 5809e Gobi™ 4G HSPA+ Mobile Broadband Card iSerial 3 bNumConfigurations 2 Signed-off-by: Patrik Halfar Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 74b669194a652d828081462589ff328e4de921fc Author: Kristian Evensen Date: Thu Jan 7 16:41:33 2016 +0100 net: qmi_wwan: Add SIMCom 7230E commit 18715b261541f35ccede9b8686ee3ebaac697d38 upstream. SIMCom 7230E is a QMI LTE module with support for most "normal" bands. Manual testing has showed that only interface five works. Cc: Bjørn Mork Signed-off-by: Kristian Evensen Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 52afbb8dfe66974f7fd2bee2581c634510f5aa9c Author: Kristian Evensen Date: Wed Jan 6 14:15:50 2016 +0100 net: qmi_wwan: Add WeTelecom-WPD600N commit e439bd4a4fdeb29488f48f14845ad35607e6302c upstream. The WeTelecom-WPD600N is an LTE module that, in addition to supporting most "normal" bands, also supports LTE over 450MHz. Manual testing showed that only interface number three replies to QMI messages. Cc: Bjørn Mork Signed-off-by: Kristian Evensen Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit f85b43b6ecffed97e39ceee3976a654bdad1757c Author: Bjørn Mork Date: Thu Dec 3 19:24:19 2015 +0100 net: qmi_wwan: remove 1199:9070 device id commit 544c8f6507303e921979ac99f46f00a88b42b6e8 upstream. This turned out to be a bootloader device ID. No need for that in this driver. It will only provide a single serial function. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c3c9b08df9e7d68fd177fd7f7661038777b24cd3 Author: Bjørn Mork Date: Thu Oct 22 14:15:58 2015 +0200 qmi_wwan: add Sierra Wireless MC74xx/EM74xx commit 0db65fcfcded76fe4f74e3ca9f4e2baf67b683ef upstream. New device IDs shamelessly lifted from the vendor driver. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 8520d62f2939ea67c9cf04e6c8e372c5db8986d7 Author: David Ward Date: Mon Aug 31 14:15:14 2015 -0400 net: qmi_wwan: Sierra Wireless MC73xx -> Sierra Wireless MC7304/MC7354 commit e704059272aae2aaa5e5ce7a76e4c27c492e947e upstream. Other Sierra Wireless MC73xx devices exist, with different USB IDs. Cc: Bjørn Mork Signed-off-by: David Ward Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 257d2caed0e3aeb9293990be05f5e99a19b5267c Author: David Ward Date: Sat Aug 15 20:12:30 2015 -0400 net: qmi_wwan: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module commit a8079092c1bbf9aec3756b35256c7816b8845af7 upstream. This is an HP-branded Sierra Wireless EM7355: https://bugzilla.redhat.com/show_bug.cgi?id=1223646#c2 Signed-off-by: David Ward Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit fd273983cfd56b0d409ac30c880a54e8118f7f37 Author: Pieter Hollants Date: Mon Jul 20 10:14:13 2015 +0200 qmi_wwan: Add support for Dell Wireless 5809e 4G Modem commit 2070c48cf2b78af89ba529c00992eaaa18df8ef7 upstream. Added the USB IDs 0x413c:0x81b1 for the "Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card", a Dell-branded Sierra Wireless EM7305 LTE card in M.2 form factor, used eg. in Dell's Latitude E7540 Notebook series. Signed-off-by: Pieter Hollants Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit fae9b2cdfaca71c0c130e2918f36b66fe6d3af5b Author: Reinhard Speyerer Date: Thu Jul 16 23:28:14 2015 +0200 qmi_wwan: add the second QMI/network interface for Sierra Wireless MC7305/MC7355 commit e3426ca7bc2957ee072f61360c2b81b4adb629ad upstream. Sierra Wireless MC7305/MC7355 with USB ID 1199:9041 also provide a second QMI/network interface like the MC73xx with USB ID 1199:68c0 on USB interface #10 when used in the appropriate USB configuration. Add the corresponding QMI_FIXED_INTF entry to the qmi_wwan driver. Please note that the second QMI/network interface is not working for early MC73xx firmware versions like 01.08.x as the device does not respond to QMI messages on the second /dev/cdc-wdm port. Signed-off-by: Reinhard Speyerer Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1c0821aea59fd433ba0e038657f0bd3ff273210e Author: Aleksander Morgado Date: Thu May 29 13:51:36 2014 +0200 net: qmi_wwan: interface #11 in Sierra Wireless MC73xx is not QMI commit fc0d6e9cd0aefbe5de5ebafb1805f2c59539725b upstream. This interface is unusable, as the cdc-wdm character device doesn't reply to any QMI command. Also, the out-of-tree Sierra Wireless GobiNet driver fully skips it. Signed-off-by: Aleksander Morgado Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c0f9aa25891bfc9e4c89b32e44323475016f694d Author: Aleksander Morgado Date: Thu May 29 13:44:45 2014 +0200 net: qmi_wwan: add additional Sierra Wireless QMI devices commit 9a793e71ebd6fc4a2649f33811589a9c4fe7f4e8 upstream. A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial Sierra Wireless drivers. Signed-off-by: Aleksander Morgado Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 0f80440d264733b0fd72c5c239239ced9ad98657 Author: Aleksander Morgado Date: Wed May 28 21:05:03 2014 +0200 net: qmi_wwan: add Netgear AirCard 341U commit 4324be1e0bab67194a263be263b7e48c176d43c7 upstream. Signed-off-by: Aleksander Morgado Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 8a14dd14f29d7b8231a9bc71e9ad54d54161cf1e Author: Bjørn Mork Date: Mon Mar 28 22:38:16 2016 +0200 qmi_wwan: add "D-Link DWM-221 B1" device id commit e84810c7b85a2d7897797b3ad3e879168a8e032a upstream. Thomas reports: "Windows: 00 diagnostics 01 modem 02 at-port 03 nmea 04 nic Linux: T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=7e19 Rev=02.32 S: Manufacturer=Mobile Connect S: Product=Mobile Connect S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage" Reported-by: Thomas Schäfer Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 5dc7196b7674167bf1e4f4bbe465cd1f75d61726 Author: Xin Long Date: Sun Feb 28 10:03:51 2016 +0800 sctp: lack the check for ports in sctp_v6_cmp_addr [ Upstream commit 40b4f0fd74e46c017814618d67ec9127ff20f157 ] As the member .cmp_addr of sctp_af_inet6, sctp_v6_cmp_addr should also check the port of addresses, just like sctp_v4_cmp_addr, cause it's invoked by sctp_cmp_addr_exact(). Now sctp_v6_cmp_addr just check the port when two addresses have different family, and lack the port check for two ipv6 addresses. that will make sctp_hash_cmp() cannot work well. so fix it by adding ports comparison in sctp_v6_cmp_addr(). Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit f3fbd1c9efd06d52c97bb15a5aad9cffd235e0e4 Author: Diego Viola Date: Tue Feb 23 12:04:04 2016 -0300 net: jme: fix suspend/resume on JMC260 [ Upstream commit ee50c130c82175eaa0820c96b6d3763928af2241 ] The JMC260 network card fails to suspend/resume because the call to jme_start_irq() was too early, moving the call to jme_start_irq() after the call to jme_reset_link() makes it work. Prior this change suspend/resume would fail unless /sys/power/pm_async=0 was explicitly specified. Relevant bug report: https://bugzilla.kernel.org/show_bug.cgi?id=112351 Signed-off-by: Diego Viola Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e6927c3f8ba5d1c4cf9a32edcaeaef4f9d3b9764 Author: Bernie Harris Date: Mon Feb 22 12:58:05 2016 +1300 tunnel: Clear IPCB(skb)->opt before dst_link_failure called [ Upstream commit 5146d1f151122e868e594c7b45115d64825aee5f ] IPCB may contain data from previous layers (in the observed case the qdisc layer). In the observed scenario, the data was misinterpreted as ip header options, which later caused the ihl to be set to an invalid value (<5). This resulted in an infinite loop in the mips implementation of ip_fast_csum. This patch clears IPCB(skb)->opt before dst_link_failure can be called for various types of tunnels. This change only applies to encapsulated ipv4 packets. The code introduced in 11c21a30 which clears all of IPCB has been removed to be consistent with these changes, and instead the opt field is cleared unconditionally in ip_tunnel_xmit. The change in ip_tunnel_xmit applies to SIT, GRE, and IPIP tunnels. The relevant vti, l2tp, and pptp functions already contain similar code for clearing the IPCB. [js] backport to 3.12: no udp_tunnel there Signed-off-by: Bernie Harris Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby