Message ID | 20231214123205.v2.1.I9d1afcaad76a3e2c0ca046dc4adbc2b632c22eda@changeid (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2,1/2] drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer | expand |
Hi, On Thu, Dec 14, 2023 at 12:32 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> > --- > > Changes in v2: > - Still read all the bytes; just don't write them all to the buffer. > > drivers/gpu/drm/bridge/parade-ps8640.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c > index 8161b1a1a4b1..dfb97fbb5be6 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -330,7 +330,8 @@ static ssize_t ps8640_aux_transfer_msg(struct drm_dp_aux *aux, > return ret; > } > > - buf[i] = data; > + if (i < msg->size) > + buf[i] = data; Ah crud. I just read over Stephen's response again and realized that in this case I'm returning the wrong length from the function. A v3 will come shortly. -Doug
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index 8161b1a1a4b1..dfb97fbb5be6 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -330,7 +330,8 @@ static ssize_t ps8640_aux_transfer_msg(struct drm_dp_aux *aux, return ret; } - buf[i] = data; + if (i < msg->size) + buf[i] = data; } }
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 v2: - Still read all the bytes; just don't write them all to the buffer. drivers/gpu/drm/bridge/parade-ps8640.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)