2020-09-15 22:28:14

by Colin King

[permalink] [raw]
Subject: [PATCH] drm/rockchip: cdn-dp: fix sign extension on an int multiply for a u64 result

From: Colin Ian King <[email protected]>

The variable bit_per_pix is a u8 and is promoted in the multiplication
to an int type and then sign extended to a u64. If the result of the
int multiplication is greater than 0x7fffffff then the upper 32 bits will
be set to 1 as a result of the sign extension. Avoid this by casting
tu_size_reg to u64 to avoid sign extension and also a potential overflow.

Addresses-Coverity: ("Unintended sign extension")
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Signed-off-by: Colin Ian King <[email protected]>
---
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index 9d2163ef4d6e..33fb4d05c506 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -658,7 +658,7 @@ int cdn_dp_config_video(struct cdn_dp_device *dp)
*/
do {
tu_size_reg += 2;
- symbol = tu_size_reg * mode->clock * bit_per_pix;
+ symbol = (u64)tu_size_reg * mode->clock * bit_per_pix;
do_div(symbol, dp->max_lanes * link_rate * 8);
rem = do_div(symbol, 1000);
if (tu_size_reg > 64) {
--
2.27.0


2021-05-28 18:59:01

by Heiko Stübner

[permalink] [raw]
Subject: Re: [PATCH] drm/rockchip: cdn-dp: fix sign extension on an int multiply for a u64 result

On Tue, 15 Sep 2020 17:20:49 +0100, Colin King wrote:
> The variable bit_per_pix is a u8 and is promoted in the multiplication
> to an int type and then sign extended to a u64. If the result of the
> int multiplication is greater than 0x7fffffff then the upper 32 bits will
> be set to 1 as a result of the sign extension. Avoid this by casting
> tu_size_reg to u64 to avoid sign extension and also a potential overflow.

Applied, thanks!

[1/1] drm/rockchip: cdn-dp: fix sign extension on an int multiply for a u64 result
commit: ce0cb93a5adb283f577cd4661f511047b5e39028

Best regards,
--
Heiko Stuebner <[email protected]>