This patch is a simplified fix to address a use-after-free in 4.14.x and
4.19.x stable kernels. The flaw is already fixed upstream, starting in
5.2, by commit 7dc40713618c ("drm/i915: Introduce a mutex for
file_priv->context_idr") as part of a more complex patch series that
isn't appropriate for backporting to stable kernels.
Expand mutex coverage, while destroying the GEM context, to include the
GEM context lookup step. This fixes a use-after-free detected by KASAN:
==================================================================
BUG: KASAN: use-after-free in i915_ppgtt_close+0x2ca/0x2f0
Write of size 1 at addr ffff8881368a8368 by task i915-poc/3124
The buggy address belongs to the object at ffff8881368a8000
which belongs to the cache kmalloc-8192 of size 8192
The buggy address is located 872 bytes inside of
8192-byte region [ffff8881368a8000, ffff8881368aa000)
The buggy address belongs to the page:
page:ffffea0004da2a00 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0
flags: 0x200000000008100(slab|head)
raw: 0200000000008100 0000000000000000 0000000000000000 0000000100030003
raw: dead000000000100 dead000000000200 ffff88822a002280 0000000000000000
page dumped because: kasan: bad access detected
bc429d9...
by
Akeem G Abodunrin <email address hidden>
drm/i915/gen9: Clear residual context state on context switch
Intel GPU Hardware prior to Gen11 does not clear EU state
during a context switch. This can result in information
leakage between contexts.
For Gen8 and Gen9, hardware provides a mechanism for
fast cleardown of the EU state, by issuing a PIPE_CONTROL
with bit 27 set. We can use this in a context batch buffer
to explicitly cleardown the state on every context switch.
As this workaround is already in place for gen8, we can borrow
the code verbatim for Gen9.
Signed-off-by: Mika Kuoppala <email address hidden>
Signed-off-by: Akeem G Abodunrin <email address hidden>
CVE-2019-14615
(backported from commit bc8a76a152c5f9ef3b48104154a65a68a8b76946)
[tyhicks: Backport to 4.15:
- Use (i915_scratch_offset(engine->i915) + 2 * CACHELINE_BYTES) in
place of LRC_PPHWSP_SCRATCH_ADDR and PIPE_CONTROL_GLOBAL_GTT_IVB in
place of PIPE_CONTROL_STORE_DATA_INDEX since we're missing commit
e1237523749e ("drm/i915/execlists: Use per-process HWSP as scratch")
- Context adjustment in gen9_init_indirectctx_bb() due to missing
commit 5ee4a7a6db8e ("drm/i915/execlists: Pull the w/a LRI emission
into a helper")
- Replace the existing WaClearSlmSpaceAtContextSwitch that was being
used for pre-production Kaby Lake]
Signed-off-by: Tyler Hicks <email address hidden>
The hv_kvp_daemon service requires the hv_kvp device and should
be started when the device appears and stopped in it disappears.
Solution is based off the one provided at https://bugzilla.redhat.com/show_bug.cgi?id=1195029#c22.
The SMCCC ARCH_WORKAROUND_1 service can indicate that although the
firmware knows about the Spectre-v2 mitigation, this particular
CPU is not vulnerable, and it is thus not necessary to call
the firmware on this CPU.
Let's use this information to our benefit.
Signed-off-by: Marc Zyngier <email address hidden>
Signed-off-by: Jeremy Linton <email address hidden>
Reviewed-by: Andre Przywara <email address hidden>
Reviewed-by: Catalin Marinas <email address hidden>
Tested-by: Stefan Wahren <email address hidden>
Signed-off-by: Will Deacon <email address hidden>
Signed-off-by: Ard Biesheuvel <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: dann frazier <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Connor Kuehl <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
The very existence of __smccc_workaround_1_hvc_* is a thinko, as
KVM will never use a HVC call to perform the branch prediction
invalidation. Even as a nested hypervisor, it would use an SMC
instruction.
Let's get rid of it.
Signed-off-by: Marc Zyngier <email address hidden>
Signed-off-by: Will Deacon <email address hidden>
Signed-off-by: Ard Biesheuvel <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: dann frazier <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Connor Kuehl <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
The missing return value in its_irq_domain_activate() would cause IRQs
to be erratically disabled/enabled in unexpected ways on certain Cavium
boards. This caused all sorts of mayhem since the state of IRQs on each
CPU would be unpredictable; maybe they'd be enabled, maybe not.
This bug was introduced by a mismerge of commit d2fd562c0c69
("irqchip/gic-v3-its: Don't bind LPI to unavailable NUMA node") over a
year ago, in Ubuntu-4.15.0-44.47. The missing return value here is
-EINVAL; add it in to fix the wild breakage.
Signed-off-by: Sultan Alsawaf <email address hidden>
Signed-off-by: dann frazier <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Connor Kuehl <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
