| Message ID | 20231214123752.v3.1.I9d1afcaad76a3e2c0ca046dc4adbc2b632c22eda@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3,1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer | expand |
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 >
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>
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
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,
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(-)