- 15 Sep, 2017 12 commits
-
-
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:
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> (backported from commit 0dec879f) Signed-off-by:
Daniel Axtens <daniel.axtens@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Colin King <colin.king@canonical.com> Signed-off-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:
Dmitry Torokhov <dmitry.torokhov@gmail.com> (backported from commit 293b915f) 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:Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
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 16 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:
-
Juerg Haefliger authored
BugLink: http://bugs.launchpad.net/bugs/1711056Signed-off-by:
-
Shrirang Bagul authored
BugLink: https://bugs.launchpad.net/bugs/1712481 This patch adds ALPS PTP sticks with pid/device id 0x120A to the list of devices supported by hid-multitouch. Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
-
Masaki Ota authored
BugLink: https://bugs.launchpad.net/bugs/1712481 Support PTP Stick and Touchpad device. This Touchpad is Precision Touchpad (PTP), and Stick Pointer data is the same as Mouse; Stick Pointer works as Mouse. [jkosina@suse.cz: changelog deuglification] Signed-off-by:
Masaki Ota <masaki.ota@jp.alps.com> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> (cherry picked from commit 504c932c) Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1712024 Ported from packages/base/any/kernels/3.18.25/patches/driver-support-intel-igb-bcm54616-phy.patch in OpenNetworkLinux https://github.com/opencomputeproject/OpenNetworkLinux/Signed-off-by:
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1682644 On a dual controller setup with multipath enabled, some MEDIUM ERRORs caused both paths to be failed, thus I/O got queued/blocked since the 'queue_if_no_path' feature is enabled by default on IPR controllers. This example disabled 'queue_if_no_path' so the I/O failure is seen at the sg_dd program. Notice that after the sg_dd test-case, both paths are in 'failed' state, and both path/priority groups are in 'enabled' state (not 'active') -- which would block I/O with 'queue_if_no_path'. # sg_dd if=/dev/dm-2 bs=4096 count=1 dio=1 verbose=4 blk_sgio=0 <...> read(unix): count=4096, res=-1 sg_dd: reading, skip=0 : Input/output error <...> # dmesg [...] sd 2:2:16:0: [sds] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [...] sd 2:2:16:0: [sds] Sense Key : Medium Error [current] [...] sd 2:2:16:0: [sds] Add. Sense: Unrecovered read error - recommend rewrite the data [...] sd 2:2:16:0: [sds] CDB: Read(10) 28 00 00 00 00 00 00 00 20 00 [...] blk_update_request: I/O error, dev sds, sector 0 [...] device-mapper: multipath: Failing path 65:32. <...> [...] device-mapper: multipath: Failing path 65:224. # multipath -l 1IBM_IPR-0_59C2AE0000001F80 dm-2 IBM ,IPR-0 59C2AE00 size=5.2T features='0' hwhandler='1 alua' wp=rw |-+- policy='service-time 0' prio=0 status=enabled | `- 2:2:16:0 sds 65:32 failed undef running `-+- policy='service-time 0' prio=0 status=enabled `- 1:2:7:0 sdae 65:224 failed undef running This is not the desired behavior. The dm-multipath explicitly checks for the MEDIUM ERROR case (and a few others) so not to fail the path (e.g., I/O to other sectors could potentially happen without problems). See dm-mpath.c :: do_end_io_bio() -> noretry_error() !->! fail_path(). The problem trace is: 1) ipr_scsi_done() // SENSE KEY/CHECK CONDITION detected, go to.. 2) ipr_erp_start() // ipr_is_gscsi() and masked_ioasc OK, go to.. 3) ipr_gen_sense() // masked_ioasc is IPR_IOASC_MED_DO_NOT_REALLOC, // so set DID_PASSTHROUGH. 4) scsi_decide_disposition() // check for DID_PASSTHROUGH and return // early on, faking a DID_OK.. *instead* // of reaching scsi_check_sense(). // Had it reached the latter, that would // set host_byte to DID_MEDIUM_ERROR. 5) scsi_finish_command() 6) scsi_io_completion() 7) __scsi_error_from_host_byte() // That would be converted to -ENODATA <...> 8) dm_softirq_done() 9) multipath_end_io() 10) do_end_io() 11) noretry_error() // And that is checked in dm-mpath :: noretry_error() // which would cause fail_path() not to be called. With this patch applied, the I/O is failed but the paths are not. This multipath device continues accepting more I/O requests without blocking. (and notice the different host byte/driver byte handling per SCSI layer). # dmesg [...] sd 2:2:7:0: [sdaf] Done: SUCCESS Result: hostbyte=0x13 driverbyte=DRIVER_OK [...] sd 2:2:7:0: [sdaf] CDB: Read(10) 28 00 00 00 00 00 00 00 40 00 [...] sd 2:2:7:0: [sdaf] Sense Key : Medium Error [current] [...] sd 2:2:7:0: [sdaf] Add. Sense: Unrecovered read error - recommend rewrite the data [...] blk_update_request: critical medium error, dev sdaf, sector 0 [...] blk_update_request: critical medium error, dev dm-6, sector 0 [...] sd 2:2:7:0: [sdaf] Done: SUCCESS Result: hostbyte=0x13 driverbyte=DRIVER_OK [...] sd 2:2:7:0: [sdaf] CDB: Read(10) 28 00 00 00 00 00 00 00 10 00 [...] sd 2:2:7:0: [sdaf] Sense Key : Medium Error [current] [...] sd 2:2:7:0: [sdaf] Add. Sense: Unrecovered read error - recommend rewrite the data [...] blk_update_request: critical medium error, dev sdaf, sector 0 [...] blk_update_request: critical medium error, dev dm-6, sector 0 [...] Buffer I/O error on dev dm-6, logical block 0, async page read # multipath -l 1IBM_IPR-0_59C2AE0000001F80 1IBM_IPR-0_59C2AE0000001F80 dm-6 IBM ,IPR-0 59C2AE00 size=5.2T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw |-+- policy='service-time 0' prio=0 status=active | `- 2:2:7:0 sdaf 65:240 active undef running `-+- policy='service-time 0' prio=0 status=enabled `- 1:2:7:0 sdh 8:112 active undef running Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 785a4704) Signed-off-by:
-
Sam Mendoza-Jonas authored
BugLink: http://bugs.launchpad.net/bugs/1711401 Commit 2def86a7 ("hvc: Convert to using interrupts instead of opal events") enabled the use of interrupts in the hvc_driver for OPAL platforms. However on machines with more than one hvc console, any console after the first will fail to register an interrupt handler in notifier_add_irq() since all consoles share the same IRQ number but do not set the IRQF_SHARED flag: genirq: Flags mismatch irq 31. 00000000 (hvc_console) vs. 00000000 (hvc_console) hvc_open: request_irq failed with rc -16. This error propagates up to hvc_open() and the console is closed, but OPAL will still generate interrupts that are not handled, leading to rcu_sched stall warnings. Set IRQF_SHARED when calling request_irq(), allowing additional consoles to start properly. This is only set for consoles handled by hvc_opal_probe(), leaving other types unaffected. Signed-off-by:
Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit bbc3dfe8) Signed-off-by:
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 In the memory offline test, the $ration was used with RANDOM as the possibility to get it offlined, correct it to become the portion of available removable memory blocks. Also ask the tool to try to offline the next available memory block if the attempt is unsuccessful. It will only fail if all removable memory blocks are busy. A nice example: $ sudo ./test.sh Test scope: 10% hotplug memory online all hot-pluggable memory in offline state: SKIPPED - no hot-pluggable memory in offline state offline 10% hot-pluggable memory in online state trying to offline 3 out of 28 memory block(s): online->offline memory1 online->offline memory10 ./test.sh: line 74: echo: write error: Resource temporarily unavailable offline_memory_expect_success 10: unexpected fail online->offline memory100 online->offline memory101 online all hot-pluggable memory in offline state: offline->online memory1 offline->online memory100 offline->online memory101 skip extra tests: debugfs is not mounted $ echo $? 0 Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> (cherry picked from commit 5ff0c60b) Signed-off-by:
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 There is no prompt for testing memory notifier error injection, added with the same echo format of other tests above. Signed-off-by:
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 Check the precentage range for -r flag in memory-hotplug test. Signed-off-by:
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 Check for hot-pluggable memory availability in prerequisite() of the memory-hotplug test. Signed-off-by:
-
