- 23 Mar, 2017 1 commit
-
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 22 Mar, 2017 14 commits
-
-
Stefan Bader authored
Signed-off-by:Stefan Bader <stefan.bader@canonical.com>
-
Stefan Bader authored
This reverts commit e6a5ccb5. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit f76c7250. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit cad5842a. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit 848b65c3. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit 38567b0e. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit 024dce01. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
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 authored
This reverts commit d8028df7. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit 3432cc02. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit 1d96b90f. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit efe57ae3. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit 105517c1. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 08 Mar, 2017 25 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Paolo Bonzini authored
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>
-
Thadeu Lima de Souza Cascardo authored
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:
-
Thadeu Lima de Souza Cascardo authored
BugLink: http://bugs.launchpad.net/bugs/1669611 This reverts commit 06393b1b. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
BugLink: http://bugs.launchpad.net/bugs/1669611 This reverts commit 70330b27. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
BugLink: http://bugs.launchpad.net/bugs/1669611 This reverts commit f2f5c290. Signed-off-by:
-
Shrirang Bagul authored
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:
-
Eric W. Biederman authored
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:
-
Long Li authored
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:
-
Long Li authored
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:
-
Dexuan Cui authored
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:
-
Jack Morgenstein authored
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:
-
Jack Morgenstein authored
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 authored
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:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Eugenia Emantayev authored
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:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1664960Signed-off-by:
-
Andrey Ryabinin authored
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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Takashi Iwai authored
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:
-
Takashi Iwai authored
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:
-
Boris Ostrovsky authored
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:
-
ojab authored
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:
-
Dave Carroll authored
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:
-
Steffen Maier authored
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:
Jens Remus <jremus@linux.vnet.ibm.com> Signed-off-by:
-
Ben Hutchings authored
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:
-
Thorsten Horstmann authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit da7061c8 upstream. The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The return value in mesh_add_vendor_ies must therefore be checked against ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with WLAN_EID_VENDOR_SPECIFIC will be rejected. Fixes: 082ebb0c ("mac80211: fix mesh beacon format") Signed-off-by:
Thorsten Horstmann <thorsten@defutech.de> Signed-off-by:
Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> [sven@narfation.org: Add commit message] Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
