- 19 Sep, 2017 8 commits
-
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1713729 commit 0f174b35 upstream. C-Media devices (at least some models) mute the playback stream when volumes are set to the minimum value. But this isn't informed via TLV and the user-space, typically PulseAudio, gets confused as if it's still played in a low volume. This patch adds the new flag, min_mute, to struct usb_mixer_elem_info for indicating that the mixer element is with the minimum-mute volume. This flag is set for known C-Media devices in snd_usb_mixer_fu_apply_quirk() in turn. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196669Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1713729 commit a8e800fe upstream. A Senheisser headset requires the typical sample-rate quirk for avoiding spurious errors from inquiring the current sample rate like: usb 1-1: 2:1: cannot get freq at ep 0x4 usb 1-1: 3:1: cannot get freq at ep 0x83 The USB ID 1395:740a has to be added to the entries in snd_usb_get_sample_rate_quirk(). Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1052580Signed-off-by:
-
Stefan Bader authored
This reverts commit a62f6d58 to be replaced by a stable upstream patch which adds the exact same USB Id to the same quirk table. BugLink: http://bugs.launchpad.net/bugs/1713729Signed-off-by:
-
Daniel Mentz authored
BugLink: http://bugs.launchpad.net/bugs/1713729 commit 7e1d90f6 upstream. commit 4842e98f ("ALSA: seq: Fix race at creating a queue") attempted to fix a race reported by syzkaller. That fix has been described as follows: " When a sequencer queue is created in snd_seq_queue_alloc(),it adds the new queue element to the public list before referencing it. Thus the queue might be deleted before the call of snd_seq_queue_use(), and it results in the use-after-free error, as spotted by syzkaller. The fix is to reference the queue object at the right time. " Even with that fix in place, syzkaller reported a use-after-free error. It specifically pointed to the last instruction "return q->queue" in snd_seq_queue_alloc(). The pointer q is being used after kfree() has been called on it. It turned out that there is still a small window where a race can happen. The window opens at snd_seq_ioctl_create_queue()->snd_seq_queue_alloc()->queue_list_add() and closes at snd_seq_ioctl_create_queue()->queueptr()->snd_use_lock_use(). Between these two calls, a different thread could delete the queue and possibly re-create a different queue in the same location in queue_list. This change prevents this situation by calling snd_use_lock_use() from snd_seq_queue_alloc() prior to calling queue_list_add(). It is then the caller's responsibility to call snd_use_lock_free(&q->use_lock). Fixes: 4842e98f ("ALSA: seq: Fix race at creating a queue") Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Daniel Mentz <danielmentz@google.com> Signed-off-by:
-
KT Liao authored
BugLink: http://bugs.launchpad.net/bugs/1713729 commit 76988690 upstream. Add 2 new IDs (ELAN0609 and ELAN060B) to the list of ACPI IDs that should be handled by the driver. Signed-off-by:
KT Liao <kt.liao@emc.com.tw> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
megha.dey@linux.intel.com authored
BugLink: http://bugs.launchpad.net/bugs/1713729 commit 8861249c upstream. It was reported that the sha1 AVX2 function(sha1_transform_avx2) is reading ahead beyond its intended data, and causing a crash if the next block is beyond page boundary: http://marc.info/?l=linux-crypto-vger&m=149373371023377 This patch makes sure that there is no overflow for any buffer length. It passes the tests written by Jan Stancek that revealed this problem: https://github.com/jstancek/sha1-avx2-crash I have re-enabled sha1-avx2 by reverting commit b82ce244 Fixes: b82ce244 ("crypto: sha1-ssse3 - Disable avx2") Originally-by:
Ilya Albrekht <ilya.albrekht@intel.com> Tested-by:
Jan Stancek <jstancek@redhat.com> Signed-off-by:
Megha Dey <megha.dey@linux.intel.com> Reported-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Thomas Bogendoerfer authored
BugLink: http://bugs.launchpad.net/bugs/1713729 commit 40981160 upstream. For 64bit kernels the lmmio_space_offset of the host bridge window isn't set correctly on systems with dino/cujo PCI host bridges. This leads to not assigned memory bars and failing drivers, which need to use these bars. Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Jan Kara authored
BugLink: http://bugs.launchpad.net/bugs/1713729 commit d76036ab upstream. audit_remove_watch_rule() drops watch's reference to parent but then continues to work with it. That is not safe as parent can get freed once we drop our reference. The following is a trivial reproducer: mount -o loop image /mnt touch /mnt/file auditctl -w /mnt/file -p wax umount /mnt auditctl -D <crash in fsnotify_destroy_mark()> Grab our own reference in audit_remove_watch_rule() earlier to make sure mark does not get freed under us. Reported-by:
Tony Jones <tonyj@suse.de> Signed-off-by:
Jan Kara <jack@suse.cz> Tested-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
- 15 Sep, 2017 14 commits
-
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1713553 The i40e driver was incorrectly assuming that we would always be pulling no more than 1 descriptor from each fragment. It is in fact possible for us to end up with the case where 2 descriptors worth of data may be pulled when a frame is larger than one of the pieces generated when aligning the payload to either 4K or pieces smaller than 16K. To adjust for this we just need to make certain to test all the way to the end of the fragments as it is possible for us to span 2 descriptors in the block before us so we need to guarantee that even the last 6 descriptors have enough data to fill a full frame. Change-ID: Ic2ecb4d6b745f447d334e66c14002152f50e2f99 Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry-picked from 841493a3 upstream) Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Acked-by:
Colin King <colin.king@canonical.com> Signed-off-by:
-
Julian Anastasov authored
BugLink: https://bugs.launchpad.net/bugs/1715812 When same struct dst_entry can be used for many different neighbours we can not use it for pending confirmations. As last step, we can remove the pending_confirm flag. Reported-by:
YueHaibing <yuehaibing@huawei.com> Fixes: 5110effe ("net: Do delayed neigh confirmation.") Fixes: f2bb4bed ("ipv4: Cache output routes in fib_info nexthops.") Signed-off-by:
Julian Anastasov <ja@ssi.bg> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 51ce8bd4) Signed-off-by:
Daniel Axtens <daniel.axtens@canonical.com> Acked-by:
-
Julian Anastasov authored
BugLink: https://bugs.launchpad.net/bugs/1715812 When same struct dst_entry can be used for many different neighbours we can not use it for pending confirmations. The datagram protocols can use MSG_CONFIRM to confirm the neighbour. When used with MSG_PROBE we do not reach the code where neighbour is confirmed, so we have to do the same slow lookup by using the dst_confirm_neigh() helper. When MSG_PROBE is not used, ip_append_data/ip6_append_data will set the skb flag dst_pending_confirm. Reported-by:
-
Julian Anastasov authored
BugLink: https://bugs.launchpad.net/bugs/1715812 Add confirm_neigh method to dst_ops and use it from IPv4 and IPv6 to lookup and confirm the neighbour. Its usage via the new helper dst_confirm_neigh() should be restricted to MSG_PROBE users for performance reasons. For XFRM prefer the last tunnel address, if present. With help from Steffen Klassert. Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Julian Anastasov authored
BugLink: https://bugs.launchpad.net/bugs/1715812 When same struct dst_entry can be used for many different neighbours we can not use it for pending confirmations. Use the new sk_dst_confirm() helper to propagate the indication from received packets to sock_confirm_neigh(). Reported-by:
-
Julian Anastasov authored
BugLink: https://bugs.launchpad.net/bugs/1715812 Add new transport flag to allow sockets to confirm neighbour. When same struct dst_entry can be used for many different neighbours we can not use it for pending confirmations. The flag is propagated from transport to every packet. It is reset when cached dst is reset. Reported-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Julian Anastasov authored
BugLink: https://bugs.launchpad.net/bugs/1715812 Add new skbuff flag to allow protocols to confirm neighbour. When same struct dst_entry can be used for many different neighbours we can not use it for pending confirmations. Add sock_confirm_neigh() helper to confirm the neighbour and use it for IPv4, IPv6 and VRF before dst_neigh_output. Signed-off-by:
-
Julian Anastasov authored
BugLink: https://bugs.launchpad.net/bugs/1715812 Add new sock flag to allow sockets to confirm neighbour. When same struct dst_entry can be used for many different neighbours we can not use it for pending confirmations. As not all call paths lock the socket use full word for the flag. Add sk_dst_confirm as replacement for dst_confirm when called for received packets. Signed-off-by:
-
Wei Wang authored
CVE-2017-14106 When tcp_disconnect() is called, inet_csk_delack_init() sets icsk->icsk_ack.rcv_mss to 0. This could potentially cause tcp_recvmsg() => tcp_cleanup_rbuf() => __tcp_select_window() call path to have division by 0 issue. So this patch initializes rcv_mss to TCP_MIN_MSS instead of 0. Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Wei Wang <weiwan@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1713884 Currently the maximum size of SMB2/3 header is set incorrectly which leads to hanging of directory listing operations on encrypted SMB3 connections. Fix this by setting the maximum size to 170 bytes that is calculated as RFC1002 length field size (4) + transform header size (52) + SMB2 header size (64) + create response size (56). Cc: <stable@vger.kernel.org> Signed-off-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <smfrench@gmail.com> Acked-by:
Sachin Prabhu <sprabhu@redhat.com> (cherry picked from commit 9e37b178) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Oscar Campos authored
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1715271 Trackpoint buttons detection fails on ThinkPad 570 and 470 series, this makes the middle button of the trackpoint to not being recogized. As I don't believe there is any trackpoint with less than 3 buttons this patch just assumes three buttons when the extended button information read fails. Signed-off-by:
Oscar Campos <oscar.campos@member.fsf.org> Acked-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
John Johansen authored
The virtualization of apparmor module parameters failed to take into account the parameters being accessed when apparmor is not enabled in some cases. It also failed to take into account that policy_admin_capable checks should not be applied to parameters specified at kernel boot as this is the callback is used before apparmor is initialized. BugLink: http://bugs.launchpad.net/bugs/1626984Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
-
Kai-Heng Feng authored
BugLink: https://bugs.launchpad.net/bugs/1708852 Similar to commit 722c5ac7 ("Input: elan_i2c - add ELAN0605 to the ACPI table"), ELAN0608 should be handled by elan_i2c. This touchpad can be found in Lenovo ideapad 320-14IKB. BugLink: https://bugs.launchpad.net/bugs/1708852Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 12 Sep, 2017 6 commits
-
-
Stefan Bader authored
Signed-off-by: -
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1708399 The order in __tlb_flush_mm_lazy is to flush TLB first and then clear the mm->context.flush_mm bit. This can lead to missed flushes as the bit can be set anytime, the order needs to be the other way aronud. But this leads to a different race, __tlb_flush_mm_lazy may be called on two CPUs concurrently. If mm->context.flush_mm is cleared first then another CPU can bypass __tlb_flush_mm_lazy although the first CPU has not done the flush yet. In a virtualized environment the time until the flush is finally completed can be arbitrarily long. Add a spinlock to serialize __tlb_flush_mm_lazy and use the function in finish_arch_post_lock_switch as well. Cc: <stable@vger.kernel.org> Reviewed-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (backported from 60f07c8e linux-next) [context adaption] Signed-off-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1708399 The local TLB flushing code keeps an additional mask in the mm.context, the cpu_attach_mask. At the time a global flush of an address space is done the cpu_attach_mask is copied to the mm_cpumask in order to avoid future global flushes in case the mm is used by a single CPU only after the flush. Trouble is that the reset of the mm_cpumask is racy against the detach of an mm address space by switch_mm. The current order is first the global TLB flush and then the copy of the cpu_attach_mask to the mm_cpumask. The order needs to be the other way around. Cc: <stable@vger.kernel.org> Reviewed-by:
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1708399 The local-clearing control of the IDTE instruction does not have any effect for the clearing-by-ASCE operation. Only the invalidation-and-clearing operation respects the local-clearing bit. Remove __tlb_flush_idte_local and simplify the batched TLB flushing code. Reviewed-by:
-
Ben Seri authored
Validate the output buffer length for L2CAP config requests and responses to avoid overflowing the stack buffer used for building the option blocks. Cc: stable@vger.kernel.org Signed-off-by:
Ben Seri <ben@armis.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> CVE-2017-1000251 (cherry-picked from commit e860d2c9) Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 07 Sep, 2017 2 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by: -
Kees Cook authored
BugLink: http://bugs.launchpad.net/bugs/1715636 Moving the x86_64 and arm64 PIE base from 0x555555554000 to 0x000100000000 broke AddressSanitizer. This is a partial revert of: eab09532 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") 02445990 ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB") The AddressSanitizer tool has hard-coded expectations about where executable mappings are loaded. The motivation for changing the PIE base in the above commits was to avoid the Stack-Clash CVEs that allowed executable mappings to get too close to heap and stack. This was mainly a problem on 32-bit, but the 64-bit bases were moved too, in an effort to proactively protect those systems (proofs of concept do exist that show 64-bit collisions, but other recent changes to fix stack accounting and setuid behaviors will minimize the impact). The new 32-bit PIE base is fine for ASan (since it matches the ET_EXEC base), so only the 64-bit PIE base needs to be reverted to let x86 and arm64 ASan binaries run again. Future changes to the 64-bit PIE base on these architectures can be made optional once a more dynamic method for dealing with AddressSanitizer is found. (e.g. always loading PIE into the mmap region for marked binaries.) Link: http://lkml.kernel.org/r/20170807201542.GA21271@beast Fixes: eab09532 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") Fixes: 02445990 ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB") Signed-off-by:
Kees Cook <keescook@chromium.org> Reported-by:
Kostya Serebryany <kcc@google.com> Acked-by:
Will Deacon <will.deacon@arm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
- 06 Sep, 2017 1 commit
-
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 28 Aug, 2017 1 commit
-
-
Kleber Sacilotto de Souza authored
Signed-off-by:
-
- 25 Aug, 2017 2 commits
-
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1712746 Check priv->wdev.wiphy before dereference. Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1712746 The wiphy may be NULL sometimes. Do not dereference when it's NULL. Signed-off-by:
-
- 24 Aug, 2017 6 commits
-
-
Juerg Haefliger authored
BugLink: http://bugs.launchpad.net/bugs/1711056Signed-off-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Acked-by:
-
Juerg Haefliger authored
BugLink: http://bugs.launchpad.net/bugs/1711056Signed-off-by:
-
Juerg Haefliger authored
BugLink: http://bugs.launchpad.net/bugs/1711056 The backported bnxt_en_bpo driver should only load for NICs that are not handled by the current bnxt_en driver. Signed-off-by:
-
Juerg Haefliger authored
BugLink: http://bugs.launchpad.net/bugs/1711056 Move the CONFIG_BNXT settings from the driver's Makefile to a dedicated Kconfig file. Signed-off-by:
-
Juerg Haefliger authored
BugLink: http://bugs.launchpad.net/bugs/1711056 Remove the following compile flags that are set by the kernel's Makefile: -g -D__LINUX Signed-off-by:
-
Juerg Haefliger authored
BugLink: http://bugs.launchpad.net/bugs/1711056 The provided Makefile is a generic out-of-tree Makefile that tries to be smart and detect the source code location plus a few other things based on the current distro. We don't need any of this since we're adding the driver as an in-tree module, so get rid of it. Signed-off-by:
-
