<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu/drm, branch v4.9.210</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/i915/gen9: Clear residual context state on context switch</title>
<updated>2020-01-14T19:04:32+00:00</updated>
<author>
<name>Akeem G Abodunrin</name>
<email>akeem.g.abodunrin@intel.com</email>
</author>
<published>2020-01-08T20:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=571233331e1910206ec365ac61e5b51e77cce3b9'/>
<id>571233331e1910206ec365ac61e5b51e77cce3b9</id>
<content type='text'>
commit bc8a76a152c5f9ef3b48104154a65a68a8b76946 upstream.

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

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 &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Akeem G Abodunrin &lt;akeem.g.abodunrin@intel.com&gt;
Cc: Kumar Valsan Prathap &lt;prathap.kumar.valsan@intel.com&gt;
Cc: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Cc: Balestrieri Francesco &lt;francesco.balestrieri@intel.com&gt;
Cc: Bloomfield Jon &lt;jon.bloomfield@intel.com&gt;
Cc: Dutt Sudeep &lt;sudeep.dutt@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bc8a76a152c5f9ef3b48104154a65a68a8b76946 upstream.

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

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 &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Akeem G Abodunrin &lt;akeem.g.abodunrin@intel.com&gt;
Cc: Kumar Valsan Prathap &lt;prathap.kumar.valsan@intel.com&gt;
Cc: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Cc: Balestrieri Francesco &lt;francesco.balestrieri@intel.com&gt;
Cc: Bloomfield Jon &lt;jon.bloomfield@intel.com&gt;
Cc: Dutt Sudeep &lt;sudeep.dutt@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ</title>
<updated>2020-01-14T19:04:27+00:00</updated>
<author>
<name>Wayne Lin</name>
<email>Wayne.Lin@amd.com</email>
</author>
<published>2020-01-03T05:50:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=43e6fb6a0c69add4496b98d4d22ddfafc3b296b1'/>
<id>43e6fb6a0c69add4496b98d4d22ddfafc3b296b1</id>
<content type='text'>
commit c4e4fccc5d52d881afaac11d3353265ef4eccb8b upstream.

[Why]
According to DP spec, it should shift left 4 digits for NO_STOP_BIT
in REMOTE_I2C_READ message. Not 5 digits.

In current code, NO_STOP_BIT is always set to zero which means I2C
master is always generating a I2C stop at the end of each I2C write
transaction while handling REMOTE_I2C_READ sideband message. This issue
might have the generated I2C signal not meeting the requirement. Take
random read in I2C for instance, I2C master should generate a repeat
start to start to read data after writing the read address. This issue
will cause the I2C master to generate a stop-start rather than a
re-start which is not expected in I2C random read.

[How]
Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
drm_dp_encode_sideband_req().

Changes since v1:(https://patchwork.kernel.org/patch/11312667/)
* Add more descriptions in commit and cc to stable

Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Wayne Lin &lt;Wayne.Lin@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200103055001.10287-1-Wayne.Lin@amd.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c4e4fccc5d52d881afaac11d3353265ef4eccb8b upstream.

[Why]
According to DP spec, it should shift left 4 digits for NO_STOP_BIT
in REMOTE_I2C_READ message. Not 5 digits.

In current code, NO_STOP_BIT is always set to zero which means I2C
master is always generating a I2C stop at the end of each I2C write
transaction while handling REMOTE_I2C_READ sideband message. This issue
might have the generated I2C signal not meeting the requirement. Take
random read in I2C for instance, I2C master should generate a repeat
start to start to read data after writing the read address. This issue
will cause the I2C master to generate a stop-start rather than a
re-start which is not expected in I2C random read.

[How]
Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
drm_dp_encode_sideband_req().

Changes since v1:(https://patchwork.kernel.org/patch/11312667/)
* Add more descriptions in commit and cc to stable

Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Wayne Lin &lt;Wayne.Lin@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200103055001.10287-1-Wayne.Lin@amd.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/mst: Fix MST sideband up-reply failure handling</title>
<updated>2020-01-12T10:24:17+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2019-05-23T21:24:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ff23a27579ed39d6f3362d579809cef513f3195f'/>
<id>ff23a27579ed39d6f3362d579809cef513f3195f</id>
<content type='text'>
[ Upstream commit d8fd3722207f154b53c80eee2cf4977c3fc25a92 ]

Fix the breakage resulting in the stacktrace below, due to tx queue
being full when trying to send an up-reply. txmsg-&gt;seqno is -1 in this
case leading to a corruption of the mstb object by

	txmsg-&gt;dst-&gt;tx_slots[txmsg-&gt;seqno] = NULL;

in process_single_up_tx_qlock().

[  +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]] set_hdr_from_dst_qlock: failed to find slot
[  +0,000015] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]] failed to send msg in q -11
[  +0,000939] BUG: kernel NULL pointer dereference, address: 00000000000005a0
[  +0,006982] #PF: supervisor write access in kernel mode
[  +0,005223] #PF: error_code(0x0002) - not-present page
[  +0,005135] PGD 0 P4D 0
[  +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
[  +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted: G     U            5.2.0-rc1+ #410
[  +0,008433] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428 04/26/2019
[  +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
[  +0,005676] RIP: 0010:queue_work_on+0x19/0x70
[  +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 &lt;f0&gt; 48 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
[  +0,018750] RSP: 0018:ffffc900007dfc50 EFLAGS: 00010006
[  +0,005222] RAX: 0000000000000046 RBX: 00000000000005a0 RCX: 0000000000000001
[  +0,007133] RDX: 000000000001b608 RSI: 0000000000000000 RDI: ffffffff82121972
[  +0,007129] RBP: 0000000000000202 R08: 0000000000000000 R09: 0000000000000001
[  +0,007129] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88847bfa5096
[  +0,007131] R13: 0000000000000010 R14: ffff88849c08f3f8 R15: 0000000000000000
[  +0,007128] FS:  0000000000000000(0000) GS:ffff88849dc80000(0000) knlGS:0000000000000000
[  +0,008083] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0,005749] CR2: 00000000000005a0 CR3: 0000000005210006 CR4: 0000000000760ee0
[  +0,007128] PKRU: 55555554
[  +0,002722] Call Trace:
[  +0,002458]  drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
[  +0,006197]  ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[  +0,005764]  drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[  +0,005623]  ? intel_dp_hpd_pulse+0x205/0x370 [i915]
[  +0,005018]  intel_dp_hpd_pulse+0x205/0x370 [i915]
[  +0,004836]  i915_digport_work_func+0xbb/0x140 [i915]
[  +0,005108]  process_one_work+0x245/0x610
[  +0,004027]  worker_thread+0x37/0x380
[  +0,003684]  ? process_one_work+0x610/0x610
[  +0,004184]  kthread+0x119/0x130
[  +0,003240]  ? kthread_park+0x80/0x80
[  +0,003668]  ret_from_fork+0x24/0x50

Cc: Lyude Paul &lt;lyude@redhat.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Lyude Paul &lt;lyude@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190523212433.9058-1-imre.deak@intel.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d8fd3722207f154b53c80eee2cf4977c3fc25a92 ]

Fix the breakage resulting in the stacktrace below, due to tx queue
being full when trying to send an up-reply. txmsg-&gt;seqno is -1 in this
case leading to a corruption of the mstb object by

	txmsg-&gt;dst-&gt;tx_slots[txmsg-&gt;seqno] = NULL;

in process_single_up_tx_qlock().

[  +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]] set_hdr_from_dst_qlock: failed to find slot
[  +0,000015] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]] failed to send msg in q -11
[  +0,000939] BUG: kernel NULL pointer dereference, address: 00000000000005a0
[  +0,006982] #PF: supervisor write access in kernel mode
[  +0,005223] #PF: error_code(0x0002) - not-present page
[  +0,005135] PGD 0 P4D 0
[  +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
[  +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted: G     U            5.2.0-rc1+ #410
[  +0,008433] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428 04/26/2019
[  +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
[  +0,005676] RIP: 0010:queue_work_on+0x19/0x70
[  +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 &lt;f0&gt; 48 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
[  +0,018750] RSP: 0018:ffffc900007dfc50 EFLAGS: 00010006
[  +0,005222] RAX: 0000000000000046 RBX: 00000000000005a0 RCX: 0000000000000001
[  +0,007133] RDX: 000000000001b608 RSI: 0000000000000000 RDI: ffffffff82121972
[  +0,007129] RBP: 0000000000000202 R08: 0000000000000000 R09: 0000000000000001
[  +0,007129] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88847bfa5096
[  +0,007131] R13: 0000000000000010 R14: ffff88849c08f3f8 R15: 0000000000000000
[  +0,007128] FS:  0000000000000000(0000) GS:ffff88849dc80000(0000) knlGS:0000000000000000
[  +0,008083] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0,005749] CR2: 00000000000005a0 CR3: 0000000005210006 CR4: 0000000000760ee0
[  +0,007128] PKRU: 55555554
[  +0,002722] Call Trace:
[  +0,002458]  drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
[  +0,006197]  ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[  +0,005764]  drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[  +0,005623]  ? intel_dp_hpd_pulse+0x205/0x370 [i915]
[  +0,005018]  intel_dp_hpd_pulse+0x205/0x370 [i915]
[  +0,004836]  i915_digport_work_func+0xbb/0x140 [i915]
[  +0,005108]  process_one_work+0x245/0x610
[  +0,004027]  worker_thread+0x37/0x380
[  +0,003684]  ? process_one_work+0x610/0x610
[  +0,004184]  kthread+0x119/0x130
[  +0,003240]  ? kthread_park+0x80/0x80
[  +0,003668]  ret_from_fork+0x24/0x50

Cc: Lyude Paul &lt;lyude@redhat.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Lyude Paul &lt;lyude@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190523212433.9058-1-imre.deak@intel.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm: limit to INT_MAX in create_blob ioctl</title>
<updated>2020-01-12T10:24:12+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2019-12-05T00:52:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a09dabbf416ba5ef824a651266405426e5dcf59a'/>
<id>a09dabbf416ba5ef824a651266405426e5dcf59a</id>
<content type='text'>
[ Upstream commit 5bf8bec3f4ce044a223c40cbce92590d938f0e9c ]

The hardened usercpy code is too paranoid ever since commit 6a30afa8c1fb
("uaccess: disallow &gt; INT_MAX copy sizes")

Code itself should have been fine as-is.

Link: http://lkml.kernel.org/r/20191106164755.31478-1-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Reported-by: syzbot+fb77e97ebf0612ee6914@syzkaller.appspotmail.com
Fixes: 6a30afa8c1fb ("uaccess: disallow &gt; INT_MAX copy sizes")
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5bf8bec3f4ce044a223c40cbce92590d938f0e9c ]

The hardened usercpy code is too paranoid ever since commit 6a30afa8c1fb
("uaccess: disallow &gt; INT_MAX copy sizes")

Code itself should have been fine as-is.

Link: http://lkml.kernel.org/r/20191106164755.31478-1-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Reported-by: syzbot+fb77e97ebf0612ee6914@syzkaller.appspotmail.com
Fixes: 6a30afa8c1fb ("uaccess: disallow &gt; INT_MAX copy sizes")
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/gma500: fix memory disclosures due to uninitialized bytes</title>
<updated>2020-01-04T12:39:27+00:00</updated>
<author>
<name>Kangjie Lu</name>
<email>kjlu@umn.edu</email>
</author>
<published>2019-10-18T04:41:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c39118738793ecdde9207bec584769ed68677b4f'/>
<id>c39118738793ecdde9207bec584769ed68677b4f</id>
<content type='text'>
[ Upstream commit ec3b7b6eb8c90b52f61adff11b6db7a8db34de19 ]

"clock" may be copied to "best_clock". Initializing best_clock
is not sufficient. The fix initializes clock as well to avoid
memory disclosures and informaiton leaks.

Signed-off-by: Kangjie Lu &lt;kjlu@umn.edu&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20191018044150.1899-1-kjlu@umn.edu
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ec3b7b6eb8c90b52f61adff11b6db7a8db34de19 ]

"clock" may be copied to "best_clock". Initializing best_clock
is not sufficient. The fix initializes clock as well to avoid
memory disclosures and informaiton leaks.

Signed-off-by: Kangjie Lu &lt;kjlu@umn.edu&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20191018044150.1899-1-kjlu@umn.edu
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/bridge: analogix-anx78xx: silence -EPROBE_DEFER warnings</title>
<updated>2020-01-04T12:39:01+00:00</updated>
<author>
<name>Brian Masney</name>
<email>masneyb@onstation.org</email>
</author>
<published>2019-08-15T00:48:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7c4180a014623326d5fd6d6ae89d5e9e83068ea7'/>
<id>7c4180a014623326d5fd6d6ae89d5e9e83068ea7</id>
<content type='text'>
[ Upstream commit 2708e876272d89bbbff811d12834adbeef85f022 ]

Silence two warning messages that occur due to -EPROBE_DEFER errors to
help cleanup the system boot log.

Signed-off-by: Brian Masney &lt;masneyb@onstation.org&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190815004854.19860-4-masneyb@onstation.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2708e876272d89bbbff811d12834adbeef85f022 ]

Silence two warning messages that occur due to -EPROBE_DEFER errors to
help cleanup the system boot log.

Signed-off-by: Brian Masney &lt;masneyb@onstation.org&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190815004854.19860-4-masneyb@onstation.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: fix r1xx/r2xx register checker for POT textures</title>
<updated>2019-12-21T09:42:34+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2019-11-26T14:41:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=768290596c368b2e7c834853ff0bcfdd08b265ae'/>
<id>768290596c368b2e7c834853ff0bcfdd08b265ae</id>
<content type='text'>
commit 008037d4d972c9c47b273e40e52ae34f9d9e33e7 upstream.

Shift and mask were reversed.  Noticed by chance.

Tested-by: Meelis Roos &lt;mroos@linux.ee&gt;
Reviewed-by: Michel Dänzer &lt;mdaenzer@redhat.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 008037d4d972c9c47b273e40e52ae34f9d9e33e7 upstream.

Shift and mask were reversed.  Noticed by chance.

Tested-by: Meelis Roos &lt;mroos@linux.ee&gt;
Reviewed-by: Michel Dänzer &lt;mdaenzer@redhat.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i810: Prevent underflow in ioctl</title>
<updated>2019-12-21T09:41:37+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2019-10-04T10:22:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6f7582ab7856e863300c8ad6c4e73f0884480918'/>
<id>6f7582ab7856e863300c8ad6c4e73f0884480918</id>
<content type='text'>
commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream.

The "used" variables here come from the user in the ioctl and it can be
negative.  It could result in an out of bounds write.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream.

The "used" variables here come from the user in the ioctl and it can be
negative.  It could result in an out of bounds write.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915/cmdparser: Fix jump whitelist clearing</title>
<updated>2019-11-12T18:16:24+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2019-11-11T16:13:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=139bb57b355ed8bef2dc619ea9e63923c245557a'/>
<id>139bb57b355ed8bef2dc619ea9e63923c245557a</id>
<content type='text'>
commit ea0b163b13ffc52818c079adb00d55e227a6da6f upstream.

When a jump_whitelist bitmap is reused, it needs to be cleared.
Currently this is done with memset() and the size calculation assumes
bitmaps are made of 32-bit words, not longs.  So on 64-bit
architectures, only the first half of the bitmap is cleared.

If some whitelist bits are carried over between successive batches
submitted on the same context, this will presumably allow embedding
the rogue instructions that we're trying to reject.

Use bitmap_zero() instead, which gets the calculation right.

Fixes: f8c08d8faee5 ("drm/i915/cmdparser: Add support for backward jumps")
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ea0b163b13ffc52818c079adb00d55e227a6da6f upstream.

When a jump_whitelist bitmap is reused, it needs to be cleared.
Currently this is done with memset() and the size calculation assumes
bitmaps are made of 32-bit words, not longs.  So on 64-bit
architectures, only the first half of the bitmap is cleared.

If some whitelist bits are carried over between successive batches
submitted on the same context, this will presumably allow embedding
the rogue instructions that we're trying to reject.

Use bitmap_zero() instead, which gets the calculation right.

Fixes: f8c08d8faee5 ("drm/i915/cmdparser: Add support for backward jumps")
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915/gen8+: Add RC6 CTX corruption WA</title>
<updated>2019-11-12T18:16:24+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2018-07-09T15:24:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00194ecfb32cab5bc20ce1308c681c47094015bd'/>
<id>00194ecfb32cab5bc20ce1308c681c47094015bd</id>
<content type='text'>
commit 7e34f4e4aad3fd34c02b294a3cf2321adf5b4438 upstream.

In some circumstances the RC6 context can get corrupted. We can detect
this and take the required action, that is disable RC6 and runtime PM.
The HW recovers from the corrupted state after a system suspend/resume
cycle, so detect the recovery and re-enable RC6 and runtime PM.

v2: rebase (Mika)
v3:
- Move intel_suspend_gt_powersave() to the end of the GEM suspend
  sequence.
- Add commit message.
v4:
- Rebased on intel_uncore_forcewake_put(i915-&gt;uncore, ...) API
  change.
v5:
- Rebased on latest upstream gt_pm refactoring.

Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7e34f4e4aad3fd34c02b294a3cf2321adf5b4438 upstream.

In some circumstances the RC6 context can get corrupted. We can detect
this and take the required action, that is disable RC6 and runtime PM.
The HW recovers from the corrupted state after a system suspend/resume
cycle, so detect the recovery and re-enable RC6 and runtime PM.

v2: rebase (Mika)
v3:
- Move intel_suspend_gt_powersave() to the end of the GEM suspend
  sequence.
- Add commit message.
v4:
- Rebased on intel_uncore_forcewake_put(i915-&gt;uncore, ...) API
  change.
v5:
- Rebased on latest upstream gt_pm refactoring.

Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
