drm_atomic_helper_setup_commit() auto-completes commit->flip_done when
state->legacy_cursor_update is true, but we now for sure that we want
a sync update when we call drm_atomic_helper_setup_commit() from
vc4_atomic_commit().
Explicitly set state->legacy_cursor_update to false to prevent this
auto-completion.
Fixes: 184d3cf4f738 ("drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
---
drivers/gpu/drm/vc4/vc4_kms.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 127468785f74..1f94b9affe4b 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -214,6 +214,12 @@ static int vc4_atomic_commit(struct drm_device *dev,
return 0;
}
+ /* We know for sure we don't want an async update here. Set
+ * state->legacy_cursor_update to false to prevent
+ * drm_atomic_helper_setup_commit() from auto-completing
+ * commit->flip_done.
+ */
+ state->legacy_cursor_update = false;
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
--
2.17.1
selinux_sctp_bind_connect() must verify if the address buffer has
sufficient length before accessing the 'sa_family' field. See
__sctp_connect() for a similar check.
The length of the whole address ('len') is already checked in the
callees.
Reported-by: Qian Cai <cai(a)gmx.us>
Fixes: d452930fd3b9 ("selinux: Add SCTP support")
Cc: <stable(a)vger.kernel.org> # 4.17+
Cc: Richard Haines <richard_c_haines(a)btinternet.com>
Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com>
---
Hi,
On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <cai(a)gmx.us> wrote:
> Running the trinity fuzzer on the latest mainline (rc2) generates this,
>
> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> [15029.887294]
> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> [15000.084786] [15029.887320] Call trace:
> [15029.915511] dump_backtrace+0x0/0x2c8
> [15029.920046] show_stack+0x24/0x30
> [15029.923367] dump_stack+0x118/0x19c
> [15029.927539] print_address_description+0x68/0x2a0
> [15029.932245] kasan_report+0x1b4/0x348
> [15029.938760] __asan_load2+0x7c/0xa0
> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
>
> [15029.950571] security_sctp_bind_connect+0x58/0x90
> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> [15029.965564] sock_common_setsockopt+0x6c/0x80
> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> [15029.974456] el0_svc_handler+0xd4/0x198
> [15029.978293] el0_svc+0x8/0xc
> [15029.981174]
> [15029.982667] Allocated by task 18081:
> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> [15029.990517] kasan_kmalloc+0xb4/0xc8
> [15029.994094] __kmalloc_node+0x1c4/0x638
> [15029.997933] kvmalloc_node+0x98/0xa8
> [15030.001511] vmemdup_user+0x34/0x128
> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> [15030.015205] sock_common_setsockopt+0x6c/0x80
> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> [15030.024096] el0_svc_handler+0xd4/0x198
> [15030.027933] el0_svc+0x8/0xc
> [15030.030814]
> [15030.032306] Freed by task 3025:
> [15030.035451] __kasan_slab_free+0x114/0x228
> [15030.039548] kasan_slab_free+0x10/0x18
> [15030.043299] kfree+0x114/0x408
> [15030.046357] selinux_sk_free_security+0x38/0x48
> [15030.050888] security_sk_free+0x3c/0x58
> [15030.054727] __sk_destruct+0x3e8/0x570
> [15030.058478] sk_destruct+0x4c/0x58
> [15030.061881] __sk_free+0x68/0x138
> [15030.065197] sk_free+0x3c/0x48
> [15030.068255] unix_release_sock+0x4a8/0x550
> [15030.072353] unix_release+0x34/0x50
> [15030.075843] __sock_release+0x74/0x110
> [15030.079593] sock_close+0x24/0x38
> [15030.082913] __fput+0x1b8/0x368
> [15030.086055] ____fput+0x20/0x30
> [15030.089199] task_work_run+0x14c/0x1a8
> [15030.092951] do_notify_resume+0x1e4/0x200
> [15030.096961] work_pending+0x8/0x14
> [15030.100363]
> [15030.101856] The buggy address belongs to the object at ffff801ec53c5080
> [15030.101856] which belongs to the cache kmalloc-128 of size 128
> [15030.114376] The buggy address is located 0 bytes inside of
> [15030.114376] 128-byte region [ffff801ec53c5080, ffff801ec53c5100)
> [15030.125939] The buggy address belongs to the page:
> [15030.130732] page:ffff7fe007b14f00 count:1 mapcount:0 mapping:ffff8016c0010480 index:0x0
> [15030.138738] flags: 0x5fffff0000000200(slab)
> [15030.142926] raw: 5fffff0000000200 ffff7fe007980608 ffff801ec000fd60 ffff8016c0010480
> [15030.150671] raw: 0000000000000000 0000000000660066 00000001ffffffff 0000000000000000
> [15030.158413] page dumped because: kasan: bad access detected
> [15030.163984]
> [15030.165476] Memory state around the buggy address:
> [15030.170269] ffff801ec53c4f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.177491] ffff801ec53c5000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.184714] >ffff801ec53c5080: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.191934] ^
> [15030.195164] ffff801ec53c5100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.202386] ffff801ec53c5180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.209607] ==================================================================
> [15030.216828] Disabling lock debugging due to kernel taint
I think I found the cause - Qian, can you test this patch if it fixes
the problem?
security/selinux/hooks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 7ce683259357..a67459eb62d5 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5318,6 +5318,9 @@ static int selinux_sctp_bind_connect(struct sock *sk, int optname,
addr_buf = address;
while (walk_size < addrlen) {
+ if (walk_size + sizeof(sa_family_t) > addrlen)
+ return -EINVAL;
+
addr = addr_buf;
switch (addr->sa_family) {
case AF_UNSPEC:
--
2.17.2
From: Jonathan Hunter <jonathanh(a)nvidia.com>
The tps6586x driver creates an irqchip that is used by its various child
devices for managing interrupts. The tps6586x-rtc device is one of its
children that uses the tps6586x irqchip. When using the tps6586x-rtc as
a wake-up device from suspend, the following is seen:
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
Disabling non-boot CPUs ...
Entering suspend state LP1
Enabling non-boot CPUs ...
CPU1 is up
tps6586x 3-0034: failed to read interrupt status
tps6586x 3-0034: failed to read interrupt status
The reason why the tps6586x interrupt status cannot be read is because
the tps6586x interrupt is not masked during suspend and when the
tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is
seen before the i2c controller has been resumed in order to read the
tps6586x interrupt status.
The tps6586x-rtc driver sets it's interrupt as a wake-up source during
suspend, which gets propagated to the parent tps6586x interrupt.
However, the tps6586x-rtc driver cannot disable it's interrupt during
suspend otherwise we would never be woken up and so the tps6586x must
disable it's interrupt instead.
Prevent the tps6586x interrupt handler from executing on exiting suspend
before the i2c controller has been resumed by disabling the tps6586x
interrupt on entering suspend and re-enabling it on resuming from
suspend.
Cc: stable(a)vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com>
Reviewed-by: Dmitry Osipenko <digetx(a)gmail.com>
Tested-by: Dmitry Osipenko <digetx(a)gmail.com>
Acked-by: Thierry Reding <treding(a)nvidia.com>
---
drivers/mfd/tps6586x.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index b89379782741..9c7925ca13cf 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -592,6 +592,29 @@ static int tps6586x_i2c_remove(struct i2c_client *client)
return 0;
}
+static int __maybe_unused tps6586x_i2c_suspend(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ if (tps6586x->client->irq)
+ disable_irq(tps6586x->client->irq);
+
+ return 0;
+}
+
+static int __maybe_unused tps6586x_i2c_resume(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ if (tps6586x->client->irq)
+ enable_irq(tps6586x->client->irq);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(tps6586x_pm_ops, tps6586x_i2c_suspend,
+ tps6586x_i2c_resume);
+
static const struct i2c_device_id tps6586x_id_table[] = {
{ "tps6586x", 0 },
{ },
@@ -602,6 +625,7 @@ static struct i2c_driver tps6586x_driver = {
.driver = {
.name = "tps6586x",
.of_match_table = of_match_ptr(tps6586x_of_match),
+ .pm = &tps6586x_pm_ops,
},
.probe = tps6586x_i2c_probe,
.remove = tps6586x_i2c_remove,
--
2.7.4
From: Jonathan Hunter <jonathanh(a)nvidia.com>
The tps6586x driver creates an irqchip that is used by its various child
devices for managing interrupts. The tps6586x-rtc device is one of its
children that uses the tps6586x irqchip. When using the tps6586x-rtc as
a wake-up device from suspend, the following is seen:
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
Disabling non-boot CPUs ...
Entering suspend state LP1
Enabling non-boot CPUs ...
CPU1 is up
tps6586x 3-0034: failed to read interrupt status
tps6586x 3-0034: failed to read interrupt status
The reason why the tps6586x interrupt status cannot be read is because
the tps6586x interrupt is not masked during suspend and when the
tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is
seen before the i2c controller has been resumed in order to read the
tps6586x interrupt status.
The tps6586x-rtc driver sets it's interrupt as a wake-up source during
suspend, which gets propagated to the parent tps6586x interrupt.
However, the tps6586x-rtc driver cannot disable it's interrupt during
suspend otherwise we would never be woken up and so the tps6586x must
disable it's interrupt instead.
Prevent the tps6586x interrupt handler from executing on exiting suspend
before the i2c controller has been resumed by disabling the tps6586x
interrupt on entering suspend and re-enabling it on resuming from
suspend.
Cc: stable(a)vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com>
---
drivers/mfd/tps6586x.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index b89379782741..9c7925ca13cf 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -592,6 +592,29 @@ static int tps6586x_i2c_remove(struct i2c_client *client)
return 0;
}
+static int __maybe_unused tps6586x_i2c_suspend(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ if (tps6586x->client->irq)
+ disable_irq(tps6586x->client->irq);
+
+ return 0;
+}
+
+static int __maybe_unused tps6586x_i2c_resume(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ if (tps6586x->client->irq)
+ enable_irq(tps6586x->client->irq);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(tps6586x_pm_ops, tps6586x_i2c_suspend,
+ tps6586x_i2c_resume);
+
static const struct i2c_device_id tps6586x_id_table[] = {
{ "tps6586x", 0 },
{ },
@@ -602,6 +625,7 @@ static struct i2c_driver tps6586x_driver = {
.driver = {
.name = "tps6586x",
.of_match_table = of_match_ptr(tps6586x_of_match),
+ .pm = &tps6586x_pm_ops,
},
.probe = tps6586x_i2c_probe,
.remove = tps6586x_i2c_remove,
--
2.7.4