linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer
@ 2023-12-14 20:37 Douglas Anderson
  2023-12-14 20:37 ` [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: " Douglas Anderson
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: Douglas Anderson @ 2023-12-14 20:37 UTC (permalink / raw)
  To: dri-devel
  Cc: Guenter Roeck, Douglas Anderson, Andrzej Hajda, Daniel Vetter,
	David Airlie, Jernej Skrabec, Jonas Karlman, Laurent Pinchart,
	Maarten Lankhorst, Maxime Ripard, Neil Armstrong, Philip Chen,
	Robert Foss, Sam Ravnborg, Stephen Boyd, Thomas Zimmermann,
	linux-kernel

While testing, I happened to notice a random crash that looked like:

  Kernel panic - not syncing: stack-protector:
  Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120

Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer
(allocated on the stack) to the aux->transfer() function. Presumably
if the aux->transfer() writes more than one byte to this buffer then
we're in a bad shape.

Dropping into kgdb, I noticed that "aux->transfer" pointed at
ps8640_aux_transfer().

Reading through ps8640_aux_transfer(), I can see that there are cases
where it could write more bytes to msg->buffer than were specified by
msg->size. This could happen if the hardware reported back something
bogus to us. Let's fix this so we never write more than msg->size
bytes. We'll still read all the bytes from the hardware just in case
the hardware requires it since the aux transfer data comes through an
auto-incrementing register.

NOTE: I have no actual way to reproduce this issue but it seems likely
this is what was happening in the crash I looked at.

Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v3:
- Never return more than msg->size as the number of bytes we read.

Changes in v2:
- Still read all the bytes; just don't write them all to the buffer.

 drivers/gpu/drm/bridge/parade-ps8640.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
index 8161b1a1a4b1..d264b80d909d 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -330,11 +330,12 @@ static ssize_t ps8640_aux_transfer_msg(struct drm_dp_aux *aux,
 				return ret;
 			}
 
-			buf[i] = data;
+			if (i < msg->size)
+				buf[i] = data;
 		}
 	}
 
-	return len;
+	return min(len, msg->size);
 }
 
 static ssize_t ps8640_aux_transfer(struct drm_dp_aux *aux,
-- 
2.43.0.472.g3155946c3a-goog


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer
  2023-12-14 20:37 [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer Douglas Anderson
@ 2023-12-14 20:37 ` Douglas Anderson
  2023-12-14 21:28   ` Guenter Roeck
                     ` (2 more replies)
  2023-12-14 21:26 ` [PATCH v3 1/2] drm/bridge: parade-ps8640: " Guenter Roeck
                   ` (2 subsequent siblings)
  3 siblings, 3 replies; 8+ messages in thread
From: Douglas Anderson @ 2023-12-14 20:37 UTC (permalink / raw)
  To: dri-devel
  Cc: Guenter Roeck, Douglas Anderson, Andrzej Hajda, Daniel Vetter,
	David Airlie, Jernej Skrabec, Jonas Karlman, Laurent Pinchart,
	Maarten Lankhorst, Maxime Ripard, Neil Armstrong, Robert Foss,
	Sam Ravnborg, Stephen Boyd, Thomas Zimmermann, linux-kernel

For aux reads, the value `msg->size` indicates the size of the buffer
provided by `msg->buffer`. We should never in any circumstances write
more bytes to the buffer since it may overflow the buffer.

In the ti-sn65dsi86 driver there is one code path that reads the
transfer length from hardware. Even though it's never been seen to be
a problem, we should make extra sure that the hardware isn't
increasing the length since doing so would cause us to overrun the
buffer.

Fixes: 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux failures")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

(no changes since v2)

Changes in v2:
- Updated patch subject to match ps8640 patch.

 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 9095d1453710..62cc3893dca5 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -527,6 +527,7 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
 	u32 request_val = AUX_CMD_REQ(msg->request);
 	u8 *buf = msg->buffer;
 	unsigned int len = msg->size;
+	unsigned int short_len;
 	unsigned int val;
 	int ret;
 	u8 addr_len[SN_AUX_LENGTH_REG + 1 - SN_AUX_ADDR_19_16_REG];
@@ -600,7 +601,8 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
 	}
 
 	if (val & AUX_IRQ_STATUS_AUX_SHORT) {
-		ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, &len);
+		ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, &short_len);
+		len = min(len, short_len);
 		if (ret)
 			goto exit;
 	} else if (val & AUX_IRQ_STATUS_NAT_I2C_FAIL) {
-- 
2.43.0.472.g3155946c3a-goog


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer
  2023-12-14 20:37 [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer Douglas Anderson
  2023-12-14 20:37 ` [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: " Douglas Anderson
@ 2023-12-14 21:26 ` Guenter Roeck
  2023-12-17  1:06 ` Stephen Boyd
  2023-12-18 16:47 ` Doug Anderson
  3 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2023-12-14 21:26 UTC (permalink / raw)
  To: Douglas Anderson
  Cc: dri-devel, Guenter Roeck, Andrzej Hajda, Daniel Vetter,
	David Airlie, Jernej Skrabec, Jonas Karlman, Laurent Pinchart,
	Maarten Lankhorst, Maxime Ripard, Neil Armstrong, Philip Chen,
	Robert Foss, Sam Ravnborg, Stephen Boyd, Thomas Zimmermann,
	linux-kernel

On Thu, Dec 14, 2023 at 12:38 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> While testing, I happened to notice a random crash that looked like:
>
>   Kernel panic - not syncing: stack-protector:
>   Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120
>
> Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer
> (allocated on the stack) to the aux->transfer() function. Presumably
> if the aux->transfer() writes more than one byte to this buffer then
> we're in a bad shape.
>
> Dropping into kgdb, I noticed that "aux->transfer" pointed at
> ps8640_aux_transfer().
>
> Reading through ps8640_aux_transfer(), I can see that there are cases
> where it could write more bytes to msg->buffer than were specified by
> msg->size. This could happen if the hardware reported back something
> bogus to us. Let's fix this so we never write more than msg->size
> bytes. We'll still read all the bytes from the hardware just in case
> the hardware requires it since the aux transfer data comes through an
> auto-incrementing register.
>
> NOTE: I have no actual way to reproduce this issue but it seems likely
> this is what was happening in the crash I looked at.
>
> Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Reviewed-by: Guenter Roeck <groeck@chromium.org>

> ---
>
> Changes in v3:
> - Never return more than msg->size as the number of bytes we read.
>
> Changes in v2:
> - Still read all the bytes; just don't write them all to the buffer.
>
>  drivers/gpu/drm/bridge/parade-ps8640.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 8161b1a1a4b1..d264b80d909d 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -330,11 +330,12 @@ static ssize_t ps8640_aux_transfer_msg(struct drm_dp_aux *aux,
>                                 return ret;
>                         }
>
> -                       buf[i] = data;
> +                       if (i < msg->size)
> +                               buf[i] = data;
>                 }
>         }
>
> -       return len;
> +       return min(len, msg->size);
>  }
>
>  static ssize_t ps8640_aux_transfer(struct drm_dp_aux *aux,
> --
> 2.43.0.472.g3155946c3a-goog
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer
  2023-12-14 20:37 ` [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: " Douglas Anderson
@ 2023-12-14 21:28   ` Guenter Roeck
  2023-12-17  1:08   ` Stephen Boyd
  2023-12-18 16:48   ` Doug Anderson
  2 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2023-12-14 21:28 UTC (permalink / raw)
  To: Douglas Anderson
  Cc: dri-devel, Guenter Roeck, Andrzej Hajda, Daniel Vetter,
	David Airlie, Jernej Skrabec, Jonas Karlman, Laurent Pinchart,
	Maarten Lankhorst, Maxime Ripard, Neil Armstrong, Robert Foss,
	Sam Ravnborg, Stephen Boyd, Thomas Zimmermann, linux-kernel

On Thu, Dec 14, 2023 at 12:38 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> For aux reads, the value `msg->size` indicates the size of the buffer
> provided by `msg->buffer`. We should never in any circumstances write
> more bytes to the buffer since it may overflow the buffer.
>
> In the ti-sn65dsi86 driver there is one code path that reads the
> transfer length from hardware. Even though it's never been seen to be
> a problem, we should make extra sure that the hardware isn't
> increasing the length since doing so would cause us to overrun the
> buffer.
>
> Fixes: 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux failures")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Reviewed-by: Guenter Roeck <groeck@chromium.org>

> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Updated patch subject to match ps8640 patch.
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 9095d1453710..62cc3893dca5 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -527,6 +527,7 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
>         u32 request_val = AUX_CMD_REQ(msg->request);
>         u8 *buf = msg->buffer;
>         unsigned int len = msg->size;
> +       unsigned int short_len;
>         unsigned int val;
>         int ret;
>         u8 addr_len[SN_AUX_LENGTH_REG + 1 - SN_AUX_ADDR_19_16_REG];
> @@ -600,7 +601,8 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
>         }
>
>         if (val & AUX_IRQ_STATUS_AUX_SHORT) {
> -               ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, &len);
> +               ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, &short_len);
> +               len = min(len, short_len);
>                 if (ret)
>                         goto exit;
>         } else if (val & AUX_IRQ_STATUS_NAT_I2C_FAIL) {
> --
> 2.43.0.472.g3155946c3a-goog
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer
  2023-12-14 20:37 [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer Douglas Anderson
  2023-12-14 20:37 ` [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: " Douglas Anderson
  2023-12-14 21:26 ` [PATCH v3 1/2] drm/bridge: parade-ps8640: " Guenter Roeck
@ 2023-12-17  1:06 ` Stephen Boyd
  2023-12-18 16:47 ` Doug Anderson
  3 siblings, 0 replies; 8+ messages in thread
From: Stephen Boyd @ 2023-12-17  1:06 UTC (permalink / raw)
  To: Douglas Anderson, dri-devel
  Cc: Guenter Roeck, Andrzej Hajda, Daniel Vetter, David Airlie,
	Jernej Skrabec, Jonas Karlman, Laurent Pinchart,
	Maarten Lankhorst, Maxime Ripard, Neil Armstrong, Philip Chen,
	Robert Foss, Sam Ravnborg, Thomas Zimmermann, linux-kernel

Quoting Douglas Anderson (2023-12-14 12:37:51)
> While testing, I happened to notice a random crash that looked like:
>
>   Kernel panic - not syncing: stack-protector:
>   Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120
>
> Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer
> (allocated on the stack) to the aux->transfer() function. Presumably
> if the aux->transfer() writes more than one byte to this buffer then
> we're in a bad shape.
>
> Dropping into kgdb, I noticed that "aux->transfer" pointed at
> ps8640_aux_transfer().
>
> Reading through ps8640_aux_transfer(), I can see that there are cases
> where it could write more bytes to msg->buffer than were specified by
> msg->size. This could happen if the hardware reported back something
> bogus to us. Let's fix this so we never write more than msg->size
> bytes. We'll still read all the bytes from the hardware just in case
> the hardware requires it since the aux transfer data comes through an
> auto-incrementing register.
>
> NOTE: I have no actual way to reproduce this issue but it seems likely
> this is what was happening in the crash I looked at.
>
> Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer
  2023-12-14 20:37 ` [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: " Douglas Anderson
  2023-12-14 21:28   ` Guenter Roeck
@ 2023-12-17  1:08   ` Stephen Boyd
  2023-12-18 16:48   ` Doug Anderson
  2 siblings, 0 replies; 8+ messages in thread
From: Stephen Boyd @ 2023-12-17  1:08 UTC (permalink / raw)
  To: Douglas Anderson, dri-devel
  Cc: Guenter Roeck, Andrzej Hajda, Daniel Vetter, David Airlie,
	Jernej Skrabec, Jonas Karlman, Laurent Pinchart,
	Maarten Lankhorst, Maxime Ripard, Neil Armstrong, Robert Foss,
	Sam Ravnborg, Thomas Zimmermann, linux-kernel

Quoting Douglas Anderson (2023-12-14 12:37:52)
> For aux reads, the value `msg->size` indicates the size of the buffer
> provided by `msg->buffer`. We should never in any circumstances write
> more bytes to the buffer since it may overflow the buffer.
>
> In the ti-sn65dsi86 driver there is one code path that reads the
> transfer length from hardware. Even though it's never been seen to be
> a problem, we should make extra sure that the hardware isn't
> increasing the length since doing so would cause us to overrun the
> buffer.
>
> Fixes: 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux failures")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer
  2023-12-14 20:37 [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer Douglas Anderson
                   ` (2 preceding siblings ...)
  2023-12-17  1:06 ` Stephen Boyd
@ 2023-12-18 16:47 ` Doug Anderson
  3 siblings, 0 replies; 8+ messages in thread
From: Doug Anderson @ 2023-12-18 16:47 UTC (permalink / raw)
  To: dri-devel
  Cc: Guenter Roeck, Andrzej Hajda, Daniel Vetter, David Airlie,
	Jernej Skrabec, Jonas Karlman, Laurent Pinchart,
	Maarten Lankhorst, Maxime Ripard, Neil Armstrong, Philip Chen,
	Robert Foss, Sam Ravnborg, Stephen Boyd, Thomas Zimmermann,
	linux-kernel

Hi,

On Thu, Dec 14, 2023 at 12:38 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> While testing, I happened to notice a random crash that looked like:
>
>   Kernel panic - not syncing: stack-protector:
>   Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120
>
> Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer
> (allocated on the stack) to the aux->transfer() function. Presumably
> if the aux->transfer() writes more than one byte to this buffer then
> we're in a bad shape.
>
> Dropping into kgdb, I noticed that "aux->transfer" pointed at
> ps8640_aux_transfer().
>
> Reading through ps8640_aux_transfer(), I can see that there are cases
> where it could write more bytes to msg->buffer than were specified by
> msg->size. This could happen if the hardware reported back something
> bogus to us. Let's fix this so we never write more than msg->size
> bytes. We'll still read all the bytes from the hardware just in case
> the hardware requires it since the aux transfer data comes through an
> auto-incrementing register.
>
> NOTE: I have no actual way to reproduce this issue but it seems likely
> this is what was happening in the crash I looked at.
>
> Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Since the patch fixes a crash, has two Reviews (even if they're both
from @chromium), and doesn't seem controversial, I didn't want a full
week and just landed it in drm-misc-fixes. If anyone is upset by this
then please shout and we can revert or I can post a followup patch.

3164c8a70073 drm/bridge: parade-ps8640: Never store more than
msg->size bytes in AUX xfer

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer
  2023-12-14 20:37 ` [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: " Douglas Anderson
  2023-12-14 21:28   ` Guenter Roeck
  2023-12-17  1:08   ` Stephen Boyd
@ 2023-12-18 16:48   ` Doug Anderson
  2 siblings, 0 replies; 8+ messages in thread
From: Doug Anderson @ 2023-12-18 16:48 UTC (permalink / raw)
  To: dri-devel
  Cc: Guenter Roeck, Andrzej Hajda, Daniel Vetter, David Airlie,
	Jernej Skrabec, Jonas Karlman, Laurent Pinchart,
	Maarten Lankhorst, Maxime Ripard, Neil Armstrong, Robert Foss,
	Sam Ravnborg, Stephen Boyd, Thomas Zimmermann, linux-kernel

Hi,

On Thu, Dec 14, 2023 at 12:38 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> For aux reads, the value `msg->size` indicates the size of the buffer
> provided by `msg->buffer`. We should never in any circumstances write
> more bytes to the buffer since it may overflow the buffer.
>
> In the ti-sn65dsi86 driver there is one code path that reads the
> transfer length from hardware. Even though it's never been seen to be
> a problem, we should make extra sure that the hardware isn't
> increasing the length since doing so would cause us to overrun the
> buffer.
>
> Fixes: 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux failures")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Updated patch subject to match ps8640 patch.
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Since the patch fixes a potential crash, has two Reviews (even if
they're both from @chromium), and doesn't seem controversial, I didn't
want a full week and just landed it in drm-misc-fixes. If anyone is
upset by this then please shout and we can revert or I can post a
followup patch.

Pushed to drm-misc-fixes:

aca58eac52b8 drm/bridge: ti-sn65dsi86: Never store more than msg->size
bytes in AUX xfer

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-12-18 16:53 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-14 20:37 [PATCH v3 1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer Douglas Anderson
2023-12-14 20:37 ` [PATCH v3 2/2] drm/bridge: ti-sn65dsi86: " Douglas Anderson
2023-12-14 21:28   ` Guenter Roeck
2023-12-17  1:08   ` Stephen Boyd
2023-12-18 16:48   ` Doug Anderson
2023-12-14 21:26 ` [PATCH v3 1/2] drm/bridge: parade-ps8640: " Guenter Roeck
2023-12-17  1:06 ` Stephen Boyd
2023-12-18 16:47 ` Doug Anderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).