Message ID | 20201113120121.33212-1-colin.king@canonical.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[] | expand |
Hi Colin. On Fri, Nov 13, 2020 at 12:01:21PM +0000, Colin King wrote: > From: Colin Ian King <colin.king@canonical.com> > > Writes to elements in the kmb->plane_status array in function > kmb_plane_atomic_disable are overrunning the array when plane_id is > more than 1 because currently the array is KMB_MAX_PLANES elements > in size and this is currently #defined as 1. Fix this by defining > KMB_MAX_PLANES to 4. I fail to follow you here. In kmb_plane_init() only one plane is allocated - with id set to 0. So for now only one plane is allocated thus kmb_plane_atomic_disable() is only called for this plane. With your change we will start allocating four planes, something that is not tested. Do I miss something? Sam
On 13/11/2020 14:55, Sam Ravnborg wrote: > Hi Colin. > > On Fri, Nov 13, 2020 at 12:01:21PM +0000, Colin King wrote: >> From: Colin Ian King <colin.king@canonical.com> >> >> Writes to elements in the kmb->plane_status array in function >> kmb_plane_atomic_disable are overrunning the array when plane_id is >> more than 1 because currently the array is KMB_MAX_PLANES elements >> in size and this is currently #defined as 1. Fix this by defining >> KMB_MAX_PLANES to 4. > > I fail to follow you here. > In kmb_plane_init() only one plane is allocated - with id set to 0. > So for now only one plane is allocated thus kmb_plane_atomic_disable() > is only called for this plane. > > With your change we will start allocating four planes, something that is > not tested. > > Do I miss something? > > Sam > The static analysis from coverity on linux-next suggested that there was an array overflow as follows: 108 static void kmb_plane_atomic_disable(struct drm_plane *plane, 109 struct drm_plane_state *state) 110 { 1. Condition 0 /* !!(!__builtin_types_compatible_p() && !__builtin_types_compatible_p()) */, taking false branch. 111 struct kmb_plane *kmb_plane = to_kmb_plane(plane); 2. assignment: Assigning: plane_id = kmb_plane->id. 112 int plane_id = kmb_plane->id; 113 struct kmb_drm_private *kmb; 114 115 kmb = to_kmb(plane->dev); 116 3. Switch case value LAYER_3. 117 switch (plane_id) { 118 case LAYER_0: 119 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE; 120 break; 121 case LAYER_1: (#2 of 4): Out-of-bounds write (OVERRUN) 122 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE; 123 break; 124 case LAYER_2: (#3 of 4): Out-of-bounds write (OVERRUN) 125 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE; 126 break; 4. equality_cond: Jumping to case LAYER_3. 127 case LAYER_3: (#1 of 4): Out-of-bounds write (OVERRUN) 5. overrun-local: Overrunning array kmb->plane_status of 1 8-byte elements at element index 3 (byte offset 31) using index plane_id (which evaluates to 3). 128 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE; 129 break; 130 } 131 (#4 of 4): Out-of-bounds write (OVERRUN) 132 kmb->plane_status[plane_id].disable = true; 133 } 134 So it seems the assignments to kmb->plane_status[plane_id] are overrunning the array since plane_status is allocated as 1 element and yet plane_id can be 0..3 I could be misunderstanding this, or it may be a false positive. Colin
Hi Colin. On Fri, Nov 13, 2020 at 03:04:34PM +0000, Colin Ian King wrote: > On 13/11/2020 14:55, Sam Ravnborg wrote: > > Hi Colin. > > > > On Fri, Nov 13, 2020 at 12:01:21PM +0000, Colin King wrote: > >> From: Colin Ian King <colin.king@canonical.com> > >> > >> Writes to elements in the kmb->plane_status array in function > >> kmb_plane_atomic_disable are overrunning the array when plane_id is > >> more than 1 because currently the array is KMB_MAX_PLANES elements > >> in size and this is currently #defined as 1. Fix this by defining > >> KMB_MAX_PLANES to 4. > > > > I fail to follow you here. > > In kmb_plane_init() only one plane is allocated - with id set to 0. > > So for now only one plane is allocated thus kmb_plane_atomic_disable() > > is only called for this plane. > > > > With your change we will start allocating four planes, something that is > > not tested. > > > > Do I miss something? > > > > Sam > > > > The static analysis from coverity on linux-next suggested that there was > an array overflow as follows: > > 108 static void kmb_plane_atomic_disable(struct drm_plane *plane, > 109 struct drm_plane_state *state) > 110 { > > 1. Condition 0 /* !!(!__builtin_types_compatible_p() && > !__builtin_types_compatible_p()) */, taking false branch. > > 111 struct kmb_plane *kmb_plane = to_kmb_plane(plane); > > 2. assignment: Assigning: plane_id = kmb_plane->id. > > 112 int plane_id = kmb_plane->id; > 113 struct kmb_drm_private *kmb; > 114 > 115 kmb = to_kmb(plane->dev); > 116 > > 3. Switch case value LAYER_3. > > 117 switch (plane_id) { > 118 case LAYER_0: > 119 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE; > 120 break; With the current code this is the only case that hits. So coverity is right that if we hit other cases that would result in a bug. But kmb_plane->id will for now not have other values than 0. So it is a subtle false positive. There is some "dead" code here - but this is in preparation for more than one layer and we will keep the code for now, unless Anitha chimes in and says otherwise. Sam > 121 case LAYER_1: > > (#2 of 4): Out-of-bounds write (OVERRUN) > > 122 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE; > 123 break; > 124 case LAYER_2: > > (#3 of 4): Out-of-bounds write (OVERRUN) > > 125 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE; > 126 break; > > 4. equality_cond: Jumping to case LAYER_3. > > 127 case LAYER_3: > > (#1 of 4): Out-of-bounds write (OVERRUN) > 5. overrun-local: Overrunning array kmb->plane_status of 1 8-byte > elements at element index 3 (byte offset 31) using index plane_id (which > evaluates to 3). > > 128 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE; > 129 break; > 130 } > 131 > > (#4 of 4): Out-of-bounds write (OVERRUN) > > 132 kmb->plane_status[plane_id].disable = true; > 133 } > 134 > > So it seems the assignments to kmb->plane_status[plane_id] are > overrunning the array since plane_status is allocated as 1 element and > yet plane_id can be 0..3 > > I could be misunderstanding this, or it may be a false positive. > > Colin
Hi Sam and Colin, > -----Original Message----- > From: Sam Ravnborg <sam@ravnborg.org> > Sent: Friday, November 13, 2020 10:02 AM > To: Colin Ian King <colin.king@canonical.com> > Cc: Chrisanthus, Anitha <anitha.chrisanthus@intel.com>; Dea, Edmund J > <edmund.j.dea@intel.com>; David Airlie <airlied@linux.ie>; Daniel Vetter > <daniel@ffwll.ch>; dri-devel@lists.freedesktop.org; kernel- > janitors@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb- > >plane_status[] > > Hi Colin. > On Fri, Nov 13, 2020 at 03:04:34PM +0000, Colin Ian King wrote: > > On 13/11/2020 14:55, Sam Ravnborg wrote: > > > Hi Colin. > > > > > > On Fri, Nov 13, 2020 at 12:01:21PM +0000, Colin King wrote: > > >> From: Colin Ian King <colin.king@canonical.com> > > >> > > >> Writes to elements in the kmb->plane_status array in function > > >> kmb_plane_atomic_disable are overrunning the array when plane_id is > > >> more than 1 because currently the array is KMB_MAX_PLANES elements > > >> in size and this is currently #defined as 1. Fix this by defining > > >> KMB_MAX_PLANES to 4. > > > > > > I fail to follow you here. > > > In kmb_plane_init() only one plane is allocated - with id set to 0. > > > So for now only one plane is allocated thus kmb_plane_atomic_disable() > > > is only called for this plane. > > > > > > With your change we will start allocating four planes, something that is > > > not tested. > > > > > > Do I miss something? > > > > > > Sam > > > > > > > The static analysis from coverity on linux-next suggested that there was > > an array overflow as follows: > > > > 108 static void kmb_plane_atomic_disable(struct drm_plane *plane, > > 109 struct drm_plane_state *state) > > 110 { > > > > 1. Condition 0 /* !!(!__builtin_types_compatible_p() && > > !__builtin_types_compatible_p()) */, taking false branch. > > > > 111 struct kmb_plane *kmb_plane = to_kmb_plane(plane); > > > > 2. assignment: Assigning: plane_id = kmb_plane->id. > > > > 112 int plane_id = kmb_plane->id; > > 113 struct kmb_drm_private *kmb; > > 114 > > 115 kmb = to_kmb(plane->dev); > > 116 > > > > 3. Switch case value LAYER_3. > > > > 117 switch (plane_id) { > > 118 case LAYER_0: > > 119 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE; > > 120 break; > > With the current code this is the only case that hits. > So coverity is right that if we hit other cases that would result in a > bug. But kmb_plane->id will for now not have other values than 0. > > So it is a subtle false positive. > There is some "dead" code here - but this is in preparation for more > than one layer and we will keep the code for now, unless Anitha chimes > in and says otherwise. Thanks Sam, I was out on Friday. Agree with Sam, let's keep the current code for now. Kmb->plane_id will not have non-zero values now. Only one plane is supported and tested currently, the extra code is in preparation for multiple planes. Thanks, Anitha > > Sam > > > 121 case LAYER_1: > > > > (#2 of 4): Out-of-bounds write (OVERRUN) > > > > 122 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE; > > 123 break; > > 124 case LAYER_2: > > > > (#3 of 4): Out-of-bounds write (OVERRUN) > > > > 125 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE; > > 126 break; > > > > 4. equality_cond: Jumping to case LAYER_3. > > > > 127 case LAYER_3: > > > > (#1 of 4): Out-of-bounds write (OVERRUN) > > 5. overrun-local: Overrunning array kmb->plane_status of 1 8-byte > > elements at element index 3 (byte offset 31) using index plane_id (which > > evaluates to 3). > > > > 128 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE; > > 129 break; > > 130 } > > 131 > > > > (#4 of 4): Out-of-bounds write (OVERRUN) > > > > 132 kmb->plane_status[plane_id].disable = true; > > 133 } > > 134 > > > > So it seems the assignments to kmb->plane_status[plane_id] are > > overrunning the array since plane_status is allocated as 1 element and > > yet plane_id can be 0..3 > > > > I could be misunderstanding this, or it may be a false positive. > > > > Colin
On 16/11/2020 16:53, Chrisanthus, Anitha wrote: > Hi Sam and Colin, > >> -----Original Message----- >> From: Sam Ravnborg <sam@ravnborg.org> >> Sent: Friday, November 13, 2020 10:02 AM >> To: Colin Ian King <colin.king@canonical.com> >> Cc: Chrisanthus, Anitha <anitha.chrisanthus@intel.com>; Dea, Edmund J >> <edmund.j.dea@intel.com>; David Airlie <airlied@linux.ie>; Daniel Vetter >> <daniel@ffwll.ch>; dri-devel@lists.freedesktop.org; kernel- >> janitors@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb- >>> plane_status[] >> >> Hi Colin. >> On Fri, Nov 13, 2020 at 03:04:34PM +0000, Colin Ian King wrote: >>> On 13/11/2020 14:55, Sam Ravnborg wrote: >>>> Hi Colin. >>>> >>>> On Fri, Nov 13, 2020 at 12:01:21PM +0000, Colin King wrote: >>>>> From: Colin Ian King <colin.king@canonical.com> >>>>> >>>>> Writes to elements in the kmb->plane_status array in function >>>>> kmb_plane_atomic_disable are overrunning the array when plane_id is >>>>> more than 1 because currently the array is KMB_MAX_PLANES elements >>>>> in size and this is currently #defined as 1. Fix this by defining >>>>> KMB_MAX_PLANES to 4. >>>> >>>> I fail to follow you here. >>>> In kmb_plane_init() only one plane is allocated - with id set to 0. >>>> So for now only one plane is allocated thus kmb_plane_atomic_disable() >>>> is only called for this plane. >>>> >>>> With your change we will start allocating four planes, something that is >>>> not tested. >>>> >>>> Do I miss something? >>>> >>>> Sam >>>> >>> >>> The static analysis from coverity on linux-next suggested that there was >>> an array overflow as follows: >>> >>> 108 static void kmb_plane_atomic_disable(struct drm_plane *plane, >>> 109 struct drm_plane_state *state) >>> 110 { >>> >>> 1. Condition 0 /* !!(!__builtin_types_compatible_p() && >>> !__builtin_types_compatible_p()) */, taking false branch. >>> >>> 111 struct kmb_plane *kmb_plane = to_kmb_plane(plane); >>> >>> 2. assignment: Assigning: plane_id = kmb_plane->id. >>> >>> 112 int plane_id = kmb_plane->id; >>> 113 struct kmb_drm_private *kmb; >>> 114 >>> 115 kmb = to_kmb(plane->dev); >>> 116 >>> >>> 3. Switch case value LAYER_3. >>> >>> 117 switch (plane_id) { >>> 118 case LAYER_0: >>> 119 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE; >>> 120 break; >> >> With the current code this is the only case that hits. >> So coverity is right that if we hit other cases that would result in a >> bug. But kmb_plane->id will for now not have other values than 0. >> >> So it is a subtle false positive. >> There is some "dead" code here - but this is in preparation for more >> than one layer and we will keep the code for now, unless Anitha chimes >> in and says otherwise. > > Thanks Sam, I was out on Friday. Agree with Sam, let's keep the current code for now. Kmb->plane_id will not have non-zero values now. > Only one plane is supported and tested currently, the extra code is in preparation for multiple planes. Thanks for the clarification. Apologies for the noise. > > Thanks, > Anitha >> >> Sam >> >>> 121 case LAYER_1: >>> >>> (#2 of 4): Out-of-bounds write (OVERRUN) >>> >>> 122 kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE; >>> 123 break; >>> 124 case LAYER_2: >>> >>> (#3 of 4): Out-of-bounds write (OVERRUN) >>> >>> 125 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE; >>> 126 break; >>> >>> 4. equality_cond: Jumping to case LAYER_3. >>> >>> 127 case LAYER_3: >>> >>> (#1 of 4): Out-of-bounds write (OVERRUN) >>> 5. overrun-local: Overrunning array kmb->plane_status of 1 8-byte >>> elements at element index 3 (byte offset 31) using index plane_id (which >>> evaluates to 3). >>> >>> 128 kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE; >>> 129 break; >>> 130 } >>> 131 >>> >>> (#4 of 4): Out-of-bounds write (OVERRUN) >>> >>> 132 kmb->plane_status[plane_id].disable = true; >>> 133 } >>> 134 >>> >>> So it seems the assignments to kmb->plane_status[plane_id] are >>> overrunning the array since plane_status is allocated as 1 element and >>> yet plane_id can be 0..3 >>> >>> I could be misunderstanding this, or it may be a false positive. >>> >>> Colin
diff --git a/drivers/gpu/drm/kmb/kmb_plane.h b/drivers/gpu/drm/kmb/kmb_plane.h index 486490f7a3ec..6f43a7ae3de6 100644 --- a/drivers/gpu/drm/kmb/kmb_plane.h +++ b/drivers/gpu/drm/kmb/kmb_plane.h @@ -43,7 +43,7 @@ enum layer_id { /* KMB_MAX_PLANES */ }; -#define KMB_MAX_PLANES 1 +#define KMB_MAX_PLANES 4 enum sub_plane_id { Y_PLANE,