BugLink: http://bugs.launchpad.net/bugs/1627730

commit ba913e4f upstream.

When mapping a page into the guest we error check using is_error_pfn(),
however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an
error HVA for the page. This can only happen on MIPS right now due to
unusual memslot management (e.g. being moved / removed / resized), or
with an Enhanced Virtual Memory (EVA) configuration where the default
KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed
in a later patch). This case will be treated as a pfn of zero, mapping
the first page of physical memory into the guest.

It would appear the MIPS KVM port wasn't updated prior to being merged
(in v3.10) to take commit 81c52c56 ("KVM: do not treat noslot pfn as
a error pfn") into account (merged v3.8), which converted a bunch of
is_error_pfn() calls to is_error_noslot_pfn(). Switch to using
is_error_noslot_pfn() instead to catch this case properly.

Fixes: 858dd5d4 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[james.hogan@imgtec.com: Backport to v4.7.y]
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1627730

commit b53e7d00 upstream.

The bootloader (U-boot) sometimes uses this timer for various delays.
It uses it as a ongoing counter, and does comparisons on the current
counter value. The timer counter is never stopped.

In some cases when the user interacts with the bootloader, or lets
it idle for some time before loading Linux, the timer may expire,
and an interrupt will be pending. This results in an unexpected
interrupt when the timer interrupt is enabled by the kernel, at
which point the event_handler isn't set yet. This results in a NULL
pointer dereference exception, panic, and no way to reboot.

Clear any pending interrupts after we stop the timer in the probe
function to avoid this.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1627730

commit 163ae1c6 upstream.

On an ext4 or f2fs filesystem with file encryption supported, a user
could set an encryption policy on any empty directory(*) to which they
had readonly access.  This is obviously problematic, since such a
directory might be owned by another user and the new encryption policy
would prevent that other user from creating files in their own directory
(for example).

Fix this by requiring inode_owner_or_capable() permission to set an
encryption policy.  This means that either the caller must own the file,
or the caller must have the capability CAP_FOWNER.

(*) Or also on any regular file, for f2fs v4.6 and later and ext4
    v4.8-rc1 and later; a separate bug fix is coming for that.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1627730

commit adb7ef60 upstream.

This might be unexpected but pages allocated for sbi->s_buddy_cache are
charged to current memory cgroup. So, GFP_NOFS allocation could fail if
current task has been killed by OOM or if current memory cgroup has no
free memory left. Block allocator cannot handle such failures here yet.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1613295

walk.iv is not assigned a value in blkcipher_walk_init. It makes iv uninitialized.
It is possibly a null value(as shown below), which is then used by aes_p8_encrypt.

This patch moves iv = walk.iv after blkcipher_walk_virt, in which walk.iv is set.

[17856.268050] Unable to handle kernel paging request for data at address 0x00000000
[17856.268212] Faulting instruction address: 0xd000000002ff04bc
7:mon> t
[link register   ] d000000002ff47b8 p8_aes_xts_crypt+0x168/0x2a0 [vmx_crypto]   (938)
[c000000013b77960] d000000002ff4794 p8_aes_xts_crypt+0x144/0x2a0 [vmx_crypto] (unreliable)
[c000000013b77a70] c000000000544d64 skcipher_decrypt_blkcipher+0x64/0x80
[c000000013b77ac0] d000000003c0175c crypt_convert+0x53c/0x620 [dm_crypt]
[c000000013b77ba0] d000000003c043fc kcryptd_crypt+0x3cc/0x440 [dm_crypt]
[c000000013b77c50] c0000000000f3070 process_one_work+0x1e0/0x590
[c000000013b77ce0] c0000000000f34c8 worker_thread+0xa8/0x660
[c000000013b77d80] c0000000000fc0b0 kthread+0x110/0x130
[c000000013b77e30] c0000000000098f0 ret_from_kernel_thread+0x5c/0x6c
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 901d3d4f)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Colin King <colin.king@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1626782

On systems with 128 CPUs, turning off TSO results in errors,

i40e 0000:03:00.0: failed to get tracking for 1 vectors for VSI 400, err=-12
i40e 0000:03:00.0: Couldn't create FDir VSI
i40e 0000:03:00.0: i40e_ptp_init: PTP not supported on eth0
i40e 0000:03:00.0: couldn't add VEB, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_ENOENT
i40e 0000:03:00.0: rebuild of switch failed: -1, will try to set up simple PF connection
i40e 0000:03:00.0 eth0: adding 00:10:e0:8a:24:b6 vid=0

Enabling FD_SB without checking availability of MSI-X vector is the
root cause. This change adds necessary check.
Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a70e407f)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

 Conflicts:
	drivers/net/ethernet/intel/i40e/i40e.h
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1626222

Since we will remove items off the list using list_del() we need
to use a safe version of the list_for_each() macro aptly named
list_for_each_safe().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 96183182)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1625986

The underlying slot hotplug registration code assumed multiple slots, but
the actual implementation is broken for multiple slots.

This went unnoticed for years do to the fact that PowerVM seems to only
ever provide a single hotplug slot per PHB.

Under qemu/kvm the hotplug slot model aligns more with x86 where
multiple slots are presented under a single PHB. As seen in the
following each additional slot after the first fails to register due to
each slot always being compared against the first child node of the PHB
in the device tree.

  rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
  rpaphp: Slot [Slot 0] registered
  rpaphp: pci_hp_register failed with error -16
  rpaphp: pci_hp_register failed with error -16
  rpaphp: pci_hp_register failed with error -16
  rpaphp: pci_hp_register failed with error -16

The registration logic is fixed so that each slot is compared
against the existing child devices of the PHB in the device tree to
determine present slots vs empty slots.

  rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
  rpaphp: Slot [C0] registered
  rpaphp: Slot [C1] registered
  rpaphp: Slot [C2] registered
  rpaphp: Slot [C3] registered
  rpaphp: Slot [C4] registered
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
[mpe: Massage changelog]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

(cherry picked from commit e2413a7d)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1628520

Commit 5706aca74fe4 ("NVMe: Don't unmap controller registers on reset"),
which backported b00a726a to the 4.4.y kernel introduced a
regression in which it didn't call pci_disable_device in the error path
of nvme_pci_enable.
Reported-by: Jiri Slaby <jslaby@suse.cz>
Embarassed-developer: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from linux-stable commit 81e9a969)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1611078

This reverts commit 63f6655e,
which is superseded by later patches.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

Ignore: yes
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

path_put() call dput() which might sleep on some paths. When it does
sleep from these code paths, the per cpu work buffer may get reused
overwriting the data that was just placed in the buffer.

This causes the following mediation to fail as the work buffer no
longer has valid data for the current operation.

BugLink: http://bugs.launchpad.net/bugs/1634753Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This is an ancient bug that was actually attrempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9 ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f4 ("fix get_user_pages bug").

In the meantime, the s390 situation has long been fixed, and we can once
more try to fix it by checking the pte_dirty() bit properly (and do it
better).  Also, the VM has become more scalable, and what was a purely
theoretical race back then has become easier to trigger.

To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.
Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Willy Tarreau <w@1wt.eu>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

CVE-2016-5195

[ saf: Adjust context for missing FOLL_REMOTE ]
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Ignore: yes
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1518457

On an AWS t2.micro instance (Xeon E5-2670, 991MiB of memory).
Occasionally (about once a day), kswapd0 falls into a busy loop and
spins on 100% CPU usage indefinitely. Reject to do the zone balance
when the memory is too small.
Signed-off-by: Dan Streetman <dan.streetman@canonical.com>
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Tested-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

Ignore: yes
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1631287

Currently, GRO can do unlimited recursion through the gro_receive
handlers.  This was fixed for tunneling protocols by limiting tunnel GRO
to one level with encap_mark, but both VLAN and TEB still have this
problem.  Thus, the kernel is vulnerable to a stack overflow, if we
receive a packet composed entirely of VLAN headers.

This patch adds a recursion counter to the GRO layer to prevent stack
overflow.  When a gro_receive function hits the recursion limit, GRO is
aborted for this skb and it is processed normally.

Fixes: 9b174d88 ("net: Add Transparent Ethernet Bridging GRO support.")
Fixes: 66e5133f ("vlan: Add GRO support for non hardware accelerated vlan")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Steve Beattie <steve.beattie@canonical.com>
[ saf: backported to xenial
  - Fix up gro_receive callback invocation in udb_gro_receive()
  - Adjust context ]
CVE-2016-7039
Acked-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1631287

This patch should fix the issues seen with a recent fix to prevent
tunnel-in-tunnel frames from being generated with GRO.  The fix itself is
correct for now as long as we do not add any devices that support
NETIF_F_GSO_GRE_CSUM.  When such a device is added it could have the
potential to mess things up due to the fact that the outer transport header
points to the outer UDP header and not the GRE header as would be expected.

Fixes: fac8e0f5 ("tunnels: Don't apply GRO to multiple layers of encapsulation.")
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c3483384)
Acked-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Steve Beattie <steve.beattie@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1631287

When drivers express support for TSO of encapsulated packets, they
only mean that they can do it for one layer of encapsulation.
Supporting additional levels would mean updating, at a minimum,
more IP length fields and they are unaware of this.

No encapsulation device expresses support for handling offloaded
encapsulated packets, so we won't generate these types of frames
in the transmit path. However, GRO doesn't have a check for
multiple levels of encapsulation and will attempt to build them.

UDP tunnel GRO actually does prevent this situation but it only
handles multiple UDP tunnels stacked on top of each other. This
generalizes that solution to prevent any kind of tunnel stacking
that would cause problems.

Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
Signed-off-by: Jesse Gross <jesse@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(backported from commit fac8e0f5)
Acked-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Steve Beattie <steve.beattie@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

Ignore: yes
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1626894

Commit b00a726a upstream.

Fix nvme_pci_enable missing initializer accidentally omitted from Xenial
backport of 30d6592f "NVMe: Don't unmap controller registers on reset"
(and homogenize comment lines with the 4.4.y-stable tree).
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>

Ignore: yes
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1626112

Patch a6b5058f results in -EREMOTE returned by is_path_accessible() in
cifs_mount() to be ignored which breaks DFS mounting.
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Aurelien Aptel <aaptel@suse.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Steve French <smfrench@gmail.com>
(cherry picked from commit de5233745cd59cf5853d963ad216067788a87594
 git://git.samba.org/sfrench/cifs-2.6.git)
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1626112

The patch
fs/cifs: make share unaccessible at root level mountable
makes use of prepaths when any component of the underlying path is
inaccessible.

When mounting 2 separate shares having different prepaths but are other
wise similar in other respects, we end up sharing superblocks when we
shouldn't be doing so.
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Tested-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: Steve French <smfrench@gmail.com>
(cherry picked from commit c1d8b24d)
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1626112

Fix memory leaks introduced by the patch
fs/cifs: make share unaccessible at root level mountable

Also move allocation of cifs_sb->prepath to cifs_setup_cifs_sb().
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Tested-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: Steve French <smfrench@gmail.com>
(backported from commit 4214ebf4)
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

UBUNTU: SAUCE: i915_bpo: drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

BugLink: http://bugs.launchpad.net/bugs/1625932

Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.

v2 by Jani, rebase on the patch caching alt increment

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
References: https://bugs.freedesktop.org/show_bug.cgi?id=67454
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Wei Shun Chen <wei.shun.chang@intel.com>
Cc: Gary C Wang <gary.c.wang@intel.com>
Cc: stable@vger.kernel.org # v4.4+ 32b421e7 drm/i915/backlight: setup and cache...
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shawn Lee <shawn.c.lee@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com
(cherry-picked from drm-intel-next-queued commit e29aff05)
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1625932

This will also be needed later on when setting up the alternate
increment in backlight enable.

Cc: Shawn Lee <shawn.c.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/9984b20bc59aee90b83caf59ce91f3fb122c9627.1474281249.git.jani.nikula@intel.com
(cherry-picked from drm-intel-next-queued commit 32b421e7)
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

Ignore: yes
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1624569

On ThunderX 88xx pass 2.x chips when TSO is offloaded to HW,
HW posts a CQE for every TSO segment transmitted. Current code
does handles this, but is prone to issues when segment sizes are
small resulting in SW processing too many CQEs and also at times
frees a SKB which is not yet transmitted.

This patch handles the errata in a different way and eliminates issues
with earlier approach, TSO packet is submitted to HW with post_cqe=0,
so that no CQE is posted upon completion of transmission of TSO packet
but a additional HDR + IMMEDIATE descriptors are added to SQ due to
which a CQE is posted and will have required info to be used while
cleanup in napi. This way only one CQE is posted for a TSO packet.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7ceb8a13)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1623627

There is a issue in HW where-in while sending GSO sized pkts
as part of TSO, if pkt len falls below configured min packet
size i.e 60, NIC will zero PAD packet and also updates IP total length.
Hence set this value to lessthan min pkt size of MAC + IP + TCP
headers, BGX will anyway do the padding to transmit 64 byte pkt
including FCS.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 57e81d44)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
tail of the write queue using tcp_add_write_queue_tail()

Then it attempts to copy user data into this fresh skb.

If the copy fails, we undo the work and remove the fresh skb.

Unfortunately, this undo lacks the change done to tp->highest_sack and
we can leave a dangling pointer (to a freed skb)

Later, tcp_xmit_retransmit_queue() can dereference this pointer and
access freed memory. For regular kernels where memory is not unmapped,
this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
returning garbage instead of tp->snd_nxt, but with various debug
features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.

This bug was found by Marco Grassi thanks to syzkaller.

Fixes: 6859d494 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb")
Reported-by: Marco Grassi <marco.gra@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

CVE-2016-6828
(cherry picked from commit bb1fceca)
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1622763

This USB headset doesn't seem to support sample rate polling, similar to this issue:

https://bugzilla.kernel.org/show_bug.cgi?id=95961

Every time something goes to interact with the device (playing a sound
file, opening the sound panel, opening web audio/video), a 10 second pause
is encountered, where dmesg prints out two messages:

  usb 2-1.2: 2:1: cannot get freq at ep 0x83
  usb 2-1.2: 2:1: cannot get freq at ep 0x83

Once the sound is playing, everything is fine. These sample rate polls
don't seem to keep happening. After waiting for maybe 30 seconds after
sound is playing, future interactions will again trigger the pause.

This 10 second pause can introduce other subtle problems. For instance,
google hangouts will sometimes timeout waiting for the sound device to
respond, and the browser tab will crash or not fully load as a result. The
sound panel often also will not display the device in the list of choices,
 and you will have to close it out. Sometimes restart pulse audio to get it
 to recognize the headset again.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1619766

Skylake adjusts some register locations, but otherwise follows the
existing model quite closely. I was able to verify that the 'ce_count'
increments when 'bad dimms' are used. The accounting of 'ce_count' and
'ue_count' is the primary functionality of interest for us. Tested on
Intel(R) Xeon(R) CPU E3-1260L v5 @ 2.90GHz.
Signed-off-by: Jason Baron <jbaron@akamai.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/1462547927-22679-1-git-send-email-jbaron@akamai.comSigned-off-by: Borislav Petkov <bp@suse.de>
(cherry picked from commit 953dee9b)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

Pending 4.8-rc merge.
BugLink: http://bugs.launchpad.net/bugs/1602724

This fixes a regression in my previous commit c21377f8 ("nvme:
Suspend all queues before deletion"), which provoked an Oops in the
removal path when removing a device that became IO incapable very early
at probe (i.e. after a failed EEH recovery).

Turns out, if the error occurred very early at the probe path, before
even configuring the admin queue, we might try to suspend the
uninitialized admin queue, accessing bad memory.

Fixes: c21377f8 ("nvme: Suspend all queues before deletion")
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Reviewed-by: Jay Freyensee <james_p_freyensee@linux.intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>