When a new xfrm state is created during an XFRM_MSG_NEWSA call we validate
the user supplied replay_esn to ensure that the size is valid and to ensure
that the replay_window size is within the allocated buffer.  However later
it is possible to update this replay_esn via a XFRM_MSG_NEWAE call.
There we again validate the size of the supplied buffer matches the
existing state and if so inject the contents.  We do not at this point
check that the replay_window is within the allocated memory.  This leads
to out-of-bounds reads and writes triggered by netlink packets.  This leads
to memory corruption and the potential for priviledge escalation.

We already attempt to validate the incoming replay information in
xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the
user is not trying to change the size of the replay state buffer which
includes the replay_esn.  It however does not check the replay_window
remains within that buffer.  Add validation of the contained replay_window.

CVE-2017-7184
Signed-off-by: Andy Whitcroft <apw@canonical.com>

Ignore: yes
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

This reverts commit e6a5ccb5.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit f76c7250.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit cad5842a.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit 848b65c3.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit 38567b0e.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit 024dce01.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Revert "UBUNTU: SAUCE: apparmor: Fix no_new_privs blocking change_onexec when using stacked namespaces"

This reverts commit 740ab2dc.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit d8028df7.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit 3432cc02.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit 1d96b90f.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit efe57ae3.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

This reverts commit 105517c1.

BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

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

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

When userspace sends KVM_SET_LAPIC, KVM schedules a check between
the vCPU's IRR and ISR and the IOAPIC redirection table, in order
to re-establish the IOAPIC's dest_map (the list of CPUs servicing
the real-time clock interrupt with the corresponding vectors).

However, __rtc_irq_eoi_tracking_restore_one was forgetting to
set dest_map->vectors.  Because of this, the IOAPIC did not process
the real-time clock interrupt EOI, ioapic->rtc_status.pending_eoi
got stuck at a non-zero value, and further RTC interrupts were
reported to userspace as coalesced.

Fixes: 9e4aabe2
Fixes: 4d99ba89
Cc: stable@vger.kernel.org
Cc: Joerg Roedel <jroedel@suse.de>
Cc: David Gilbert <dgilbert@redhat.com>
Reviewed-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit b0eaf450)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>

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

This reverts commit 40f7a7e0.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

This reverts commit 06393b1b.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

This reverts commit 70330b27.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

This reverts commit f2f5c290.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

Dell Caracalla IoT gateways sport a Redpine RS9113 WLAN-BT combo card.
This patch adds Host AP mode support to the Redpine RS9113 driver.
Vendor release version: 0.9.8.3 (Beta)

Other fixes:
- Connection drop issue with multiple APs/mobile phone hotspots
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

To support unprivileged users mounting filesystems two permission
checks have to be performed: a test to see if the user allowed to
create a mount in the mount namespace, and a test to see if
the user is allowed to access the specified filesystem.

The automount case is special in that mounting the original filesystem
grants permission to mount the sub-filesystems, to any user who
happens to stumble across the their mountpoint and satisfies the
ordinary filesystem permission checks.

Attempting to handle the automount case by using override_creds
almost works.  It preserves the idea that permission to mount
the original filesystem is permission to mount the sub-filesystem.
Unfortunately using override_creds messes up the filesystems
ordinary permission checks.

Solve this by being explicit that a mount is a submount by introducing
vfs_submount, and using it where appropriate.

vfs_submount uses a new mount internal mount flags MS_SUBMOUNT, to let
sget and friends know that a mount is a submount so they can take appropriate
action.

sget and sget_userns are modified to not perform any permission checks
on submounts.

follow_automount is modified to stop using override_creds as that
has proven problemantic.

do_mount is modified to always remove the new MS_SUBMOUNT flag so
that we know userspace will never by able to specify it.

autofs4 is modified to stop using current_real_cred that was put in
there to handle the previous version of submount permission checking.

cifs is modified to pass the mountpoint all of the way down to vfs_submount.

debugfs is modified to pass the mountpoint all of the way down to
trace_automount by adding a new parameter.  To make this change easier
a new typedef debugfs_automount_t is introduced to capture the type of
the debugfs automount function.

Cc: stable@vger.kernel.org
Fixes: 069d5ac9 ("autofs:  Fix automounts by using current_real_cred()->uid")
Fixes: aeaa4a79 ("fs: Call d_automount with the filesystems creds")
Reviewed-by: Trond Myklebust <trond.myklebust@primarydata.com>
Reviewed-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(backported from commit 93faccbb linux-next)
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

A PCI_EJECT message can arrive at the same time we are calling
pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS
message or in create_root_hv_pci_bus(), in this case we could potentailly
modify the bus from multiple places. Properly lock the bus access.

Thanks Dexuan Cui <decui@microsoft.com> for pointing out the race
condition in create_root_hv_pci_bus().
Signed-off-by: Long Li <longli@microsoft.com>
Reported-by: Xiaofeng Wang <xiaofwan@redhat.com>
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

hv_pci_devices_present is called in hv_pci_remove when we remove a PCI
device from host (e.g. by disabling SRIOV on a device). In hv_pci_remove,
the bus is already removed before the call, so we don't need to rescan the
bus in the workqueue scheduled from hv_pci_devices_present. By introducing
status hv_pcibus_removed, we can avoid this situation.
Signed-off-by: Long Li <longli@microsoft.com>
Reported-by: Xiaofeng Wang <xiaofwan@redhat.com>
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

The devfn of 00:02.0 is 0x10.  devfn_to_wslot(0x10) == 0x2, and
wslot_to_devfn(0x2) should be 0x10, while it's 0x2 in the current code.

Due to this, hv_eject_device_work() -> pci_get_domain_bus_and_slot()
returns NULL and pci_stop_and_remove_bus_device() is not called.

Later when the real device driver's .remove() is invoked by
hv_pci_remove() -> pci_stop_root_bus(), some warnings can be noticed
because the VM has lost the access to the underlying device at that
time.
Signed-off-by: Jake Oshins <jakeo@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Haiyang Zhang <haiyangz@microsoft.com>
CC: stable@vger.kernel.org
CC: K. Y. Srinivasan <kys@microsoft.com>
CC: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

Some Hypervisors detach VFs from VMs by instantly causing an FLR event
to be generated for a VF.

In the mlx4 case, this will cause that VF's comm channel to be disabled
before the VM has an opportunity to invoke the VF device's "shutdown"
method.

The result is that the VF driver on the VM will experience a command
timeout during the shutdown process when the Hypervisor does not deliver
a command-completion event to the VM.

To avoid FW command timeouts on the VM when the driver's shutdown method
is invoked, we detect the absence of the VF's comm channel at the very
start of the shutdown process. If the comm-channel has already been
disabled, we cause all FW commands during the device shutdown process to
immediately return success (and thus avoid all command timeouts).
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d585df1c)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

Save the qp context flags byte containing the flag disabling vlan stripping
in the RESET to INIT qp transition, rather than in the INIT to RTR
transition. Per the firmware spec, the flags in this byte are active
in the RESET to INIT transition.

As a result of saving the flags in the incorrect qp transition, when
switching dynamically from VGT to VST and back to VGT, the vlan
remained stripped (as is required for VST) and did not return to
not-stripped (as is required for VGT).

Fixes: f0f829bf ("net/mlx4_core: Add immediate activate for VGT->VST->VGT")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7c3945bc)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

In function mlx4_cq_completion() and mlx4_cq_event(), the
radix_tree_lookup requires a rcu_read_lock.
This is mandatory: if another core frees the CQ, it could
run the radix_tree_node_rcu_free() call_rcu() callback while
its being used by the radix tree lookup function.

Additionally, in function mlx4_cq_event(), since we are adding
the rcu lock around the radix-tree lookup, we no longer need to take
the spinlock. Also, the synchronize_irq() call for the async event
eliminates the need for incrementing the cq reference count in
mlx4_cq_event().

Other changes:
1. In function mlx4_cq_free(), replace spin_lock_irq with spin_lock:
   we no longer take this spinlock in the interrupt context.
   The spinlock here, therefore, simply protects against different
   threads simultaneously invoking mlx4_cq_free() for different cq's.

2. In function mlx4_cq_free(), we move the radix tree delete to before
   the synchronize_irq() calls. This guarantees that we will not
   access this cq during any subsequent interrupts, and therefore can
   safely free the CQ after the synchronize_irq calls. The rcu_read_lock
   in the interrupt handlers only needs to protect against corrupting the
   radix tree; the interrupt handlers may access the cq outside the
   rcu_read_lock due to the synchronize_irq calls which protect against
   premature freeing of the cq.

3. In function mlx4_cq_event(), we change the mlx_warn message to mlx4_dbg.

4. We leave the cq reference count mechanism in place, because it is
   still needed for the cq completion tasklet mechanism.

Fixes: 6d90aa5c ("net/mlx4_core: Make sure there are no pending async events when freeing CQ")
Fixes: 225c7b1f ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 291c566a)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

Single send WQE in RX buffer should be stamped with software
ownership in order to prevent the flow of QP in error in FW
once UPDATE_QP is called.

Fixes: 9f519f68 ('mlx4_en: Not using Shared Receive Queues')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6496bbf0)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1664960Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

commit 5351fbb1 upstream.

page_flip_completed() dereferences 'work' variable after executing
queue_work(). This is not safe as the 'work' item might be already freed
by queued work:

    BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr ffff8803dc010f90
    Call Trace:
     __asan_report_load8_noabort+0x59/0x80
     page_flip_completed+0x3ff/0x490
     intel_finish_page_flip_mmio+0xe3/0x130
     intel_pipe_handle_vblank+0x2d/0x40
     gen8_irq_handler+0x4a7/0xed0
     __handle_irq_event_percpu+0xf6/0x860
     handle_irq_event_percpu+0x6b/0x160
     handle_irq_event+0xc7/0x1b0
     handle_edge_irq+0x1f4/0xa50
     handle_irq+0x41/0x70
     do_IRQ+0x9a/0x200
     common_interrupt+0x89/0x89

    Freed:
     kfree+0x113/0x4d0
     intel_unpin_work_fn+0x29a/0x3b0
     process_one_work+0x79e/0x1b70
     worker_thread+0x611/0x1460
     kthread+0x241/0x3a0
     ret_from_fork+0x27/0x40

Move queue_work() after	trace_i915_flip_complete() to fix this.

Fixes: e5510fac ("drm/i915: add tracepoints for flip requests & completions")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126143211.24013-1-aryabinin@virtuozzo.com
(cherry picked from commit 05c41f92)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

commit 37a7ea4a upstream.

snd_seq_pool_done() syncs with closing of all opened threads, but it
aborts the wait loop with a timeout, and proceeds to the release
resource even if not all threads have been closed.  The timeout was 5
seconds, and if you run a crazy stuff, it can exceed easily, and may
result in the access of the invalid memory address -- this is what
syzkaller detected in a bug report.

As a fix, let the code graduate from naiveness, simply remove the loop
timeout.

BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.comReported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

commit 4842e98f upstream.

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.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

commit 74470954 upstream.

rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
queue->rx.sring which is set to NULL in xennet_disconnect_backend().
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

commit ffdadd68 upstream.

MPI2 controllers sometimes got lost (i.e. disappear from
/sys/bus/pci/devices) if ASMP is enabled.
Signed-off-by: Slava Kardakov <ojab@ojab.ru>
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60644Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

commit 8af8e1c2 upstream.

commit 78cbccd3 ("aacraid: Fix for KDUMP driver hang")

caused a problem on older controllers which do not support MSI-x (namely
ASR3405,ASR3805). This patch conditionalizes the previous patch to
controllers which support MSI-x

Fixes: 78cbccd3 ("aacraid: Fix for KDUMP driver hang")
Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Signed-off-by: Dave Carroll <david.carroll@microsemi.com>
Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

commit 2dfa6688 upstream.

Dan Carpenter kindly reported:
<quote>
The patch d27a7cb9: "zfcp: trace on request for open and close of
WKA port" from Aug 10, 2016, leads to the following static checker
warning:

	drivers/s390/scsi/zfcp_fsf.c:1615 zfcp_fsf_open_wka_port()
	warn: 'req' was already freed.

drivers/s390/scsi/zfcp_fsf.c
  1609          zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT);
  1610          retval = zfcp_fsf_req_send(req);
  1611          if (retval)
  1612                  zfcp_fsf_req_free(req);
                                          ^^^
Freed.

  1613  out:
  1614          spin_unlock_irq(&qdio->req_q_lock);
  1615          if (req && !IS_ERR(req))
  1616                  zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id);
                                                                  ^^^^^^^^^^^
Use after free.

  1617          return retval;
  1618  }

Same thing for zfcp_fsf_close_wka_port() as well.
</quote>

Rather than relying on req being NULL (or ERR_PTR) for all cases where
we don't want to trace or should not trace,
simply check retval which is unconditionally initialized with -EIO != 0
and it can only become 0 on successful retval = zfcp_fsf_req_send(req).
With that we can also remove the then again unnecessary unconditional
initialization of req which was introduced with that earlier commit.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Suggested-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: d27a7cb9 ("zfcp: trace on request for open and close of WKA port")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

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

Commit a50af86d "netvsc: reduce maximum GSO size" was wrongly
backported to 4.4-stable.  The maximum size needs to be set before the
net device is registered, in netvsc_probe().
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>