- 06 Apr, 2017 7 commits
-
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1667239 If a process dumps core while owning a cxl file descriptor obtained from an AFU driver (e.g. cxlflash) through the cxl_get_fd() API, the following error occurs: [ 868.027591] Unable to handle kernel paging request for data at address ... [ 868.027778] Faulting instruction address: 0xc00000000035edb0 cpu 0x8c: Vector: 300 (Data Access) at [c000003c688275e0] pc: c00000000035edb0: elf_core_dump+0xd60/0x1300 lr: c00000000035ed80: elf_core_dump+0xd30/0x1300 sp: c000003c68827860 msr: 9000000100009033 dar: c dsisr: 40000000 current = 0xc000003c68780000 paca = 0xc000000001b73200 softe: 0 irq_happened: 0x01 pid = 46725, comm = hxesurelock enter ? for help [c000003c68827a60] c00000000036948c do_coredump+0xcec/0x11e0 [c000003c68827c20] c0000000000ce9e0 get_signal+0x540/0x7b0 [c000003c68827d10] c000000000017354 do_signal+0x54/0x2b0 [c000003c68827e00] c00000000001777c do_notify_resume+0xbc/0xd0 [c000003c68827e30] c000000000009838 ret_from_except_lite+0x64/0x68 --- Exception: 300 (Data Access) at 00003fff98ad2918 The root cause is that the address_space structure for the file doesn't define a 'host' member. When cxl allocates a file descriptor, it's using the anonymous inode to back the file, but allocates a private address_space for each context. The private address_space allows to track memory allocation for each context. cxl doesn't define the 'host' member of the address space, i.e. the inode. We don't want to define it as the anonymous inode, since there's no longer a 1-to-1 relation between address_space and inode. To fix it, instead of using the anonymous inode, we introduce a simple pseudo filesystem so that cxl can allocate its own inodes. So we now have one inode for each file and address_space. The pseudo filesystem is only mounted on the first allocation of a file descriptor by cxl_get_fd(). Tested with cxlflash. Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Reviewed-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (backported from commit bdecf76e) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Conflicts: drivers/misc/cxl/api.c Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Signed-off-by:
Brad Figg <brad.figg@canonical.com>
-
Alex Ng authored
BugLink: http://bugs.launchpad.net/bugs/1470250 If a FREEZE operation takes too long, the driver may time out and move on to another operation. The daemon is unaware of this and attempts to notify the driver that the FREEZE succeeded. This results in an error from the driver and the daemon leaves the filesystem in frozen state. Fix this by thawing the filesystem and continuing. Signed-off-by:
Alex Ng <alexng@messages.microsoft.com> Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Alex Ng authored
BugLink: http://bugs.launchpad.net/bugs/1470250 Increase the timeout of backup operations. When system is under I/O load, it needs more time to freeze. These timeout values should also match the host timeout values more closely. Signed-off-by:
Alex Ng <alexng@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit b357fd39) Signed-off-by:
-
Larry Finger authored
BugLink: http://bugs.launchpad.net/bugs/1666421 These drivers need to be able to reference "struct ieee80211_hw" from the driver's private data, and vice versa. The USB driver failed to store the address of ieee80211_hw in the private data. Although this bug has been present for a long time, it was not exposed until commit ba9f93f8 ("rtlwifi: Fix enter/exit power_save"). Fixes: ba9f93f8 ("rtlwifi: Fix enter/exit power_save") Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> (cherry picked from commit 60f59ce0) Signed-off-by:
-
Andrew Lutomirski authored
BugLink: https://bugs.launchpad.net/bugs/1666401 nvme wants a module parameter that overrides the default latency tolerance. This makes it easy for nvme to reflect that default in sysfs. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 034e7906) Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Colin King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1656259 Sync with zfs to enable zfs to respect RSIZE_LIMIT limits, using: - backport of zfs upstream commit 933ec999511f3d29de005bfa8966ae007b161c0f ("Retire .write/.read file operations") - backport of zfs upstream commit 4b908d32200b6e5c7b5115322b6c8d25e770daa0 ("Linux 4.8 compat: posix_acl_valid()") to facilitate changes in posix_acl_valid. Acked-by:
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 31 Mar, 2017 5 commits
-
-
Stefan Bader authored
Signed-off-by: -
Andrey Konovalov authored
When calculating po->tp_hdrlen + po->tp_reserve the result can overflow. Fix by checking that tp_reserve <= INT_MAX on assign. Signed-off-by:
Andrey Konovalov <andreyknvl@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> BugLink: https://bugs.launchpad.net/bugs/1678009 CVE-2017-7308 (cherry picked from commit bcc5364b linux-net) Signed-off-by:
Andy Whitcroft <apw@canonical.com>
-
Andrey Konovalov authored
When calculating rb->frames_per_block * req->tp_block_nr the result can overflow. Add a check that tp_block_size * tp_block_nr <= UINT_MAX. Since frames_per_block <= tp_block_size, the expression would never overflow. Signed-off-by:
-
Andrey Konovalov authored
Subtracting tp_sizeof_priv from tp_block_size and casting to int to check whether one is less then the other doesn't always work (both of them are unsigned ints). Compare them as is instead. Also cast tp_sizeof_priv to u64 before using BLK_PLUS_PRIV, as it can overflow inside BLK_PLUS_PRIV otherwise. Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 24 Mar, 2017 3 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Andy Whitcroft authored
Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to wrapping issues. To ensure we are correctly ensuring that the two ESN structures are the same size compare both the overall size as reported by xfrm_replay_state_esn_len() and the internal length are the same. CVE-2017-7184 Signed-off-by: -
Andy Whitcroft authored
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:
-
- 23 Mar, 2017 1 commit
-
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:
-
- 22 Mar, 2017 14 commits
-
-
Stefan Bader authored
Signed-off-by: -
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 10 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:
-
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:
-
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:
"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:
-
