- 06 Nov, 2019 9 commits
-
-
Jon Bloomfield authored
The previous patch has killed support for secure batches on gen6+, and hence the cmdparsers master tables are now dead code. Remove them. Signed-off-by:
Jon Bloomfield <jon.bloomfield@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> CVE-2019-0155 [tjaalton: backport to i915_bpo - Modify *_reg_tables and find_reg(), use the 4.9-stable backport as inspiration. - The previous two cherry-picks were needed for this.] Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Michal Srb authored
The find_reg function was assuming that there is always at least one table in reg_tables. It is not always true. In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0, implying that no register-accessing commands are allowed. However, the command tables include commands such as MI_STORE_REGISTER_MEM. When trying to check such command, the find_reg would dereference NULL pointer. Now it will just return NULL meaning that the register was not found and the command will be rejected. Fixes: 76ff480e ("drm/i915/cmdparser: Use binary search for faster register lookup") Signed-off-by:
Michal Srb <msrb@suse.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205142916.27092-2-msrb@suse.com Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
A significant proportion of the cmdparsing time for some batches is the cost to find the register in the mmiotable. We ensure that those tables are in ascending order such that we could do a binary search if it was ever merited. It is. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-38-chris@chris-wilson.co.uk CVE-2019-0155 (cherry picked from commit 76ff480e) Signed-off-by:
-
Jon Bloomfield authored
Retroactively stop reporting support for secure batches through the api for gen6+ so that older binaries trigger the fallback path instead. Older binaries use secure batches pre gen6 to access resources that are not available to normal usermode processes. However, all known userspace explicitly checks for HAS_SECURE_BATCHES before relying on the secure batch feature. Since there are no known binaries relying on this for newer gens we can kill secure batches from gen6, via I915_PARAM_HAS_SECURE_BATCHES. Signed-off-by:
-
Jon Bloomfield authored
We're about to introduce some new tables for later gens, and the current naming for the gen7 tables will no longer make sense. Signed-off-by:
-
Chris Wilson authored
GVT is not propagating the PTE bits, and is always setting the read-write bit, thus breaking read-only support. Signed-off-by:
-
Jon Bloomfield authored
Hook up the flags to allow read-only ppGTT mappings for gen8+ v2: Include a selftest to check that writes to a readonly PTE are dropped v3: Don't duplicate cpu_check() as we can just reuse it, and even worse don't wholesale copy the theory-of-operation comment from igt_ctx_exec without changing it to explain the intention behind the new test! v4: Joonas really likes magic mystery values Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-2-chris@chris-wilson.co.uk (backported from commit 250f8c81) CVE-2019-0155 [tjaalton: backport to i915_bpo - ggtt_vm doesn't exist, use ggtt->base - dev_priv doesn't have gtt, use ggtt instead] Signed-off-by:
-
Jon Bloomfield authored
We can set a bit inside the ppGTT PTE to indicate a page is read-only; writes from the GPU will be discarded. We can use this to protect pages and in particular support read-only userptr mappings (necessary for importing PROT_READ vma). Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 21 Oct, 2019 31 commits
-
-
Khalid Elmously authored
Signed-off-by:Khalid Elmously <khalid.elmously@canonical.com>
-
Khalid Elmously authored
BugLink: https://bugs.launchpad.net/bugs/1848780 This driver was removed in Ubuntu commit 74fb80c7f1b7 ("USB: rio500: Remove Rio 500 kernel driver"). Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
-
Khalid Elmously authored
BugLink: https://bugs.launchpad.net/bugs/1849051 Properties: no-test-build Signed-off-by:
-
Khalid Elmously authored
Ignore: yes Signed-off-by: -
Tyler Hicks authored
Nicolas Waisman noticed that even though noa_len is checked for a compatible length it's still possible to overrun the buffers of p2pinfo since there's no check on the upper bound of noa_num. Bounds check noa_num against P2P_MAX_NOA_NUM using the minimum of the two. CVE-2019-17666 Reported-by:
Nicolas Waisman <nico@semmle.com> Suggested-by:
Ping-Ke Shih <pkshih@realtek.com> [tyhicks: Reuse nearly all of a commit message written by Laura Abbott] Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Andrea Righi <andrea.righi@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1848780Signed-off-by:
-
Janakarajan Natarajan authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 454de1e7 upstream. As per "AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions", MWAITX EAX[7:4]+1 specifies the optional hint of the optimized C-state. For C0 state, EAX[7:4] should be set to 0xf. Currently, a value of 0xf is set for EAX[3:0] instead of EAX[7:4]. Fix this by changing MWAITX_DISABLE_CSTATES from 0xf to 0xf0. This hasn't had any implications so far because setting reserved bits in EAX is simply ignored by the CPU. [ bp: Fixup comment in delay_mwaitx() and massage. ] Signed-off-by:
Janakarajan Natarajan <Janakarajan.Natarajan@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Frederic Weisbecker <frederic@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "x86@kernel.org" <x86@kernel.org> Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20191007190011.4859-1-Janakarajan.Natarajan@amd.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 194c2c74 upstream. As instances may have different tracers available, we need to look at the trace_array descriptor that shows the list of the available tracers for the instance. But there's a race between opening the file and an admin deleting the instance. The trace_array_get() needs to be called before accessing the trace_array. Cc: stable@vger.kernel.org Fixes: 607e2ea1 ("tracing: Set up infrastructure to allow tracers for instances") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 30045f21 upstream. Since commit c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") USB drivers must always balance their runtime PM gets and puts, including when the driver has already been unbound from the interface. Leaving the interface with a positive PM usage counter would prevent a later bound driver from suspending the device. Note that runtime PM has never actually been enabled for this driver since the support_autosuspend flag in its usb_driver struct is not set. Fixes: c2b71462 ("USB: core: Fix bug caused by duplicate interface PM usage counter") Cc: stable <stable@vger.kernel.org> Acked-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191001084908.2003-5-johan@kernel.orgSigned-off-by:
-
Pavel Shilovsky authored
BugLink: https://bugs.launchpad.net/bugs/1848780 [ Upstream commit c82e5ac7 ] Currently the client indicates that a dentry is stale when inode numbers or type types between a local inode and a remote file don't match. If this is the case attributes is not being copied from remote to local, so, it is already known that the local copy has stale metadata. That's why the inode needs to be marked for revalidation in order to tell the VFS to lookup the dentry again before openning a file. This prevents unexpected stale errors to be returned to the user space when openning a file. Cc: <stable@vger.kernel.org> Signed-off-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Ross Lagerwall authored
BugLink: https://bugs.launchpad.net/bugs/1848780 [ Upstream commit a108471b ] Commit 7196ac11 ("Fix to check Unique id and FileType when client refer file directly.") checks whether the uniqueid of an inode has changed when getting the inode info, but only when using the UNIX extensions. Add a similar check for SMB2+, since this can be done without an extra network roundtrip. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Navid Emamdoost authored
BugLink: https://bugs.launchpad.net/bugs/1848780 [ Upstream commit 5bdea606 ] In fbtft_framebuffer_alloc the error handling path should take care of releasing frame buffer after it is allocated via framebuffer_alloc, too. Therefore, in two failure cases the goto destination is changed to address this issue. Fixes: c296d5f9 ("staging: fbtft: core support") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Reviewed-by:
Dan Carpenter <dan.carpenter@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20190930030949.28615-1-navid.emamdoost@gmail.comSigned-off-by:
-
Suzuki K Poulose authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 28c5dcb2 upstream Now that we have a clear understanding of the sign of a feature, rename the routines to reflect the sign, so that it is not misused. The cpuid_feature_extract_field() now accepts a 'sign' parameter. This makes sure that the arm64_ftr_value() extracts the feature field properly for signed fields. Cc: stable@vger.kernel.org # v4.4 Signed-off-by:
Suzuki K. Poulose <suzuki.poulose@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Suzuki K Poulose authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit ff96f7bc usptream Use the appropriate accessor for the feature bit by keeping track of the sign of the feature. This is a pre-requisite for the commit 28c5dcb2 upstream, which fixes the arm64_ftr_value() for signed feature fields. Cc: stable@vger.kernel.org # v4.4 Signed-off-by:
-
Michal Hocko authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit b0f53dbc upstream. Partially revert 16db3d3f ("kernel/sysctl.c: threads-max observe limits") because the patch is causing a regression to any workload which needs to override the auto-tuning of the limit provided by kernel. set_max_threads is implementing a boot time guesstimate to provide a sensible limit of the concurrently running threads so that runaways will not deplete all the memory. This is a good thing in general but there are workloads which might need to increase this limit for an application to run (reportedly WebSpher MQ is affected) and that is simply not possible after the mentioned change. It is also very dubious to override an admin decision by an estimation that doesn't have any direct relation to correctness of the kernel operation. Fix this by dropping set_max_threads from sysctl_max_threads so any value is accepted as long as it fits into MAX_THREADS which is important to check because allowing more threads could break internal robust futex restriction. While at it, do not use MIN_THREADS as the lower boundary because it is also only a heuristic for automatic estimation and admin might have a good reason to stop new threads to be created even when below this limit. This became more severe when we switched x86 from 4k to 8k kernel stacks. Starting since 6538b8ea ("x86_64: expand kernel stack to 16K") (3.16) we use THREAD_SIZE_ORDER = 2 and that halved the auto-tuned value. In the particular case 3.12 kernel.threads-max = 515561 4.4 kernel.threads-max = 200000 Neither of the two values is really insane on 32GB machine. I am not sure we want/need to tune the max_thread value further. If anything the tuning should be removed altogether if proven not useful in general. But we definitely need a way to override this auto-tuning. Link: http://lkml.kernel.org/r/20190922065801.GB18814@dhcp22.suse.cz Fixes: 16db3d3f ("kernel/sysctl.c: threads-max observe limits") Signed-off-by:
Michal Hocko <mhocko@suse.com> Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Pavel Shilovsky authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 0b3d0ef9 upstream. Mark inode for force revalidation if LOOKUP_REVAL flag is set. This tells the client to actually send a QueryInfo request to the server to obtain the latest metadata in case a directory or a file were changed remotely. Only do that if the client doesn't have a lease for the file to avoid unneeded round trips to the server. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Pavel Shilovsky authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 30573a82 upstream. Currently if the client identifies problems when processing metadata returned in CREATE response, the open handle is being leaked. This causes multiple problems like a file missing a lease break by that client which causes high latencies to other clients accessing the file. Another side-effect of this is that the file can't be deleted. Fix this by closing the file after the client hits an error after the file was opened and the open descriptor wasn't returned to the user space. Also convert -ESTALE to -EOPENSTALE to allow the VFS to revalidate a dentry and retry the open. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ian Rogers authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 7d4c85b7 upstream. The 'test_dir' variable is assigned to the 'release' array which is out-of-scope 3 lines later. Extend the scope of the 'release' array so that an out-of-scope array isn't accessed. Bug detected by clang's address sanitizer. Fixes: 07bc5c69 ("perf tools: Make fetch_kernel_version() publicly available") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by:
Ian Rogers <irogers@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lore.kernel.org/lkml/20190926220018.25402-1-irogers@google.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
David Frey authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 82f30156 upstream. When an end-of-conversion interrupt is received after performing a single-shot reading of the light sensor, the driver was waking up the result ready queue before checking opt->ok_to_ignore_lock to determine if it should unlock the mutex. The problem occurred in the case where the other thread woke up and changed the value of opt->ok_to_ignore_lock to false prior to the interrupt thread performing its read of the variable. In this case, the mutex would be unlocked twice. Signed-off-by:
David Frey <dpfrey@gmail.com> Reviewed-by:
Andreas Dannenberg <dannenberg@ti.com> Fixes: 94a9b7b1 ("iio: light: add support for TI's opt3001 light sensor") Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Marco Felsch authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit c62dd449 upstream. Since commit 0f7ddcc1 ("iio:adc:ad799x: Write default config on probe and reset alert status on probe") the error path is wrong since it leaves the vref regulator on. Fix this by disabling both regulators. Fixes: 0f7ddcc1 ("iio:adc:ad799x: Write default config on probe and reset alert status on probe") Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Reviewed-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Navid Emamdoost authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 80b15db5 upstream. In vt6655_probe, if vnt_init() fails the cleanup code needs to be called like other error handling cases. The call to device_free_info() is added. Fixes: 67013f2c ("staging: vt6655: mac80211 conversion add main mac80211 functions") Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 726b55d0 upstream. The driver was accessing its struct usb_device in its release() callback without holding a reference. This would lead to a use-after-free whenever the device was disconnected while the character device was still open. Fixes: fef526ca ("USB: legousbtower: remove custom debug macro") Cc: stable <stable@vger.kernel.org> # 3.12 Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 0b074f69 upstream. The driver would return with a nonzero open count in case the reset control request failed. This would prevent any further attempts to open the char dev until the device was disconnected. Fix this by incrementing the open count only on successful open. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit cd81e6fa upstream. The driver is using its struct usb_device pointer as an inverted disconnected flag, but was setting it to NULL before making sure all completion handlers had run. This could lead to a NULL-pointer dereference in a number of dev_dbg and dev_err statements in the completion handlers which relies on said pointer. Fix this by unconditionally stopping all I/O and preventing resubmissions by poisoning the interrupt URBs at disconnect and using a dedicated disconnected flag. This also makes sure that all I/O has completed by the time the disconnect callback returns. Fixes: 9d974b2a ("USB: legousbtower.c: remove err() usage") Fixes: fef526ca ("USB: legousbtower: remove custom debug macro") Fixes: 4dae9963 ("USB: legotower: remove custom debug macro and module parameter") Cc: stable <stable@vger.kernel.org> # 3.5 Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 33a78132 upstream. Fix a potential deadlock if disconnect races with open. Since commit d4ead16f ("USB: prevent char device open/deregister race") core holds an rw-semaphore while open is called and when releasing the minor number during deregistration. This can lead to an ABBA deadlock if a driver takes a lock in open which it also holds during deregistration. This effectively reverts commit 78663ecc ("USB: disconnect open race in legousbtower") which needlessly introduced this issue after a generic fix for this race had been added to core by commit d4ead16f ("USB: prevent char device open/deregister race"). Fixes: 78663ecc ("USB: disconnect open race in legousbtower") Cc: stable <stable@vger.kernel.org> # 2.6.24 Reported-by: syzbot+f9549f5ee8a5416f0b95@syzkaller.appspotmail.com Tested-by: syzbot+f9549f5ee8a5416f0b95@syzkaller.appspotmail.com Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 1d427be4 upstream. Make sure to check for short transfers when retrieving the version information at probe to avoid leaking uninitialised slab data when logging it. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Yoshihiro Shimoda authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 4d599cd3 upstream. According to usb_ep_set_halt()'s description, __usbhsg_ep_set_halt_wedge() should return -EAGAIN if the IN endpoint has any queue or data. Otherwise, this driver is possible to cause just STALL without sending a short packet data on g_mass_storage driver, and then a few resetting a device happens on a host side during a usb enumaration. Fixes: 2f98382d ("usb: renesas_usbhs: Add Renesas USBHS Gadget") Cc: <stable@vger.kernel.org> # v3.0+ Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1569924633-322-3-git-send-email-yoshihiro.shimoda.uh@renesas.comSigned-off-by:
-
Yoshihiro Shimoda authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 1aae1394 upstream. The commit 97664a20 ("usb: renesas_usbhs: shrink spin lock area") had added a usbhsg_pipe_disable() calling into __usbhsg_ep_set_halt_wedge() accidentally. But, this driver should not call the usbhsg_pipe_disable() because the function discards all queues. So, this patch removes it. Fixes: 97664a20 ("usb: renesas_usbhs: shrink spin lock area") Cc: <stable@vger.kernel.org> # v3.1+ Signed-off-by:
-
Jacky.Cao@sony.com authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 2636d49b upstream. The power budget for SuperSpeed mode should be 900 mA according to USB specification, so set the power budget to 900mA for dummy_start_ss which is only used for SuperSpeed mode. If the max power consumption of SuperSpeed device is larger than 500 mA, insufficient available bus power error happens in usb_choose_configuration function when the device connects to dummy hcd. Signed-off-by:
Jacky Cao <Jacky.Cao@sony.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/16EA1F625E922C43B00B9D82250220500871CDE5@APYOKXMS108.ap.sony.comSigned-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit 177238c3 upstream. Add missing bulk-in endpoint sanity check to prevent uninitialised stack data from being reported to the system log and used as endpoint addresses. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Reported-by: syzbot+5630ca7c3b2be5c9da5e@syzkaller.appspotmail.com Signed-off-by:
Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20191003070931.17009-1-johan@kernel.orgSigned-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1848780 commit eb7f5a49 upstream. Make sure to stop all I/O on disconnect by adding a disconnected flag which is used to prevent new I/O from being started and by stopping all ongoing I/O before returning. This also fixes a potential use-after-free on driver unbind in case the driver data is freed before the completion handler has run. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> # 7bbe990cSigned-off-by:
-
