Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-16 Thread Colin Ian King
On 16/11/2020 16:53, Chrisanthus, Anitha wrote:
> Hi Sam and Colin,
> 
>> -Original Message-
>> From: Sam Ravnborg 
>> Sent: Friday, November 13, 2020 10:02 AM
>> To: Colin Ian King 
>> Cc: Chrisanthus, Anitha ; Dea, Edmund J
>> ; David Airlie ; Daniel Vetter
>> ; dri-de...@lists.freedesktop.org; kernel-
>> janit...@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 +, Colin Ian King wrote:
>>> On 13/11/2020 14:55, Sam Ravnborg wrote:
>>>> Hi Colin.
>>>>
>>>> On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
>>>>> From: Colin Ian King 
>>>>>
>>>>> 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.
>>>
>>> 111struct kmb_plane *kmb_plane = to_kmb_plane(plane);
>>>
>>>2. assignment: Assigning: plane_id = kmb_plane->id.
>>>
>>> 112int plane_id = kmb_plane->id;
>>> 113struct kmb_drm_private *kmb;
>>> 114
>>> 115kmb = to_kmb(plane->dev);
>>> 116
>>>
>>>3. Switch case value LAYER_3.
>>>
>>> 117switch (plane_id) {
>>> 118case LAYER_0:
>>> 119kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE;
>>> 120break;
>>
>> 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
>>
>>> 121case LAYER_1:
>>>
>>>(#2 of 4): Out-of-bounds write (OVERRUN)
>>>
>>> 122kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
>>> 123break;
>>> 124case LAYER_2:
>>>
>>>(#3 of 4): Out-of-bounds write (OVERRUN)
>>>
>>> 125kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
>>> 126break;
>>>
>>>4. equality_cond: Jumping to case LAYER_3.
>>>
>>> 127case 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).
>>>
>>> 128kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
>>> 129break;
>>> 130}
>>> 131
>>>
>>>(#4 of 4): Out-of-bounds write (OVERRUN)
>>>
>>> 132kmb->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



RE: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-16 Thread Chrisanthus, Anitha
Hi Sam and Colin,

> -Original Message-
> From: Sam Ravnborg 
> Sent: Friday, November 13, 2020 10:02 AM
> To: Colin Ian King 
> Cc: Chrisanthus, Anitha ; Dea, Edmund J
> ; David Airlie ; Daniel Vetter
> ; dri-de...@lists.freedesktop.org; kernel-
> janit...@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 +, Colin Ian King wrote:
> > On 13/11/2020 14:55, Sam Ravnborg wrote:
> > > Hi Colin.
> > >
> > > On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
> > >> From: Colin Ian King 
> > >>
> > >> 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.
> >
> > 111struct kmb_plane *kmb_plane = to_kmb_plane(plane);
> >
> >2. assignment: Assigning: plane_id = kmb_plane->id.
> >
> > 112int plane_id = kmb_plane->id;
> > 113struct kmb_drm_private *kmb;
> > 114
> > 115kmb = to_kmb(plane->dev);
> > 116
> >
> >3. Switch case value LAYER_3.
> >
> > 117switch (plane_id) {
> > 118case LAYER_0:
> > 119kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE;
> > 120break;
> 
> 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
> 
> > 121case LAYER_1:
> >
> >(#2 of 4): Out-of-bounds write (OVERRUN)
> >
> > 122kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
> > 123break;
> > 124case LAYER_2:
> >
> >(#3 of 4): Out-of-bounds write (OVERRUN)
> >
> > 125kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
> > 126break;
> >
> >4. equality_cond: Jumping to case LAYER_3.
> >
> > 127case 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).
> >
> > 128kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
> > 129break;
> > 130}
> > 131
> >
> >(#4 of 4): Out-of-bounds write (OVERRUN)
> >
> > 132kmb->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


Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-13 Thread Sam Ravnborg
Hi Colin.
On Fri, Nov 13, 2020 at 03:04:34PM +, Colin Ian King wrote:
> On 13/11/2020 14:55, Sam Ravnborg wrote:
> > Hi Colin.
> > 
> > On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
> >> From: Colin Ian King 
> >>
> >> 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.
> 
> 111struct kmb_plane *kmb_plane = to_kmb_plane(plane);
> 
>2. assignment: Assigning: plane_id = kmb_plane->id.
> 
> 112int plane_id = kmb_plane->id;
> 113struct kmb_drm_private *kmb;
> 114
> 115kmb = to_kmb(plane->dev);
> 116
> 
>3. Switch case value LAYER_3.
> 
> 117switch (plane_id) {
> 118case LAYER_0:
> 119kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE;
> 120break;

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

> 121case LAYER_1:
> 
>(#2 of 4): Out-of-bounds write (OVERRUN)
> 
> 122kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
> 123break;
> 124case LAYER_2:
> 
>(#3 of 4): Out-of-bounds write (OVERRUN)
> 
> 125kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
> 126break;
> 
>4. equality_cond: Jumping to case LAYER_3.
> 
> 127case 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).
> 
> 128kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
> 129break;
> 130}
> 131
> 
>(#4 of 4): Out-of-bounds write (OVERRUN)
> 
> 132kmb->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


Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-13 Thread Colin Ian King
On 13/11/2020 14:55, Sam Ravnborg wrote:
> Hi Colin.
> 
> On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
>> From: Colin Ian King 
>>
>> 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.

111struct kmb_plane *kmb_plane = to_kmb_plane(plane);

   2. assignment: Assigning: plane_id = kmb_plane->id.

112int plane_id = kmb_plane->id;
113struct kmb_drm_private *kmb;
114
115kmb = to_kmb(plane->dev);
116

   3. Switch case value LAYER_3.

117switch (plane_id) {
118case LAYER_0:
119kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE;
120break;
121case LAYER_1:

   (#2 of 4): Out-of-bounds write (OVERRUN)

122kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
123break;
124case LAYER_2:

   (#3 of 4): Out-of-bounds write (OVERRUN)

125kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
126break;

   4. equality_cond: Jumping to case LAYER_3.

127case 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).

128kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
129break;
130}
131

   (#4 of 4): Out-of-bounds write (OVERRUN)

132kmb->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


Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-13 Thread Sam Ravnborg
Hi Colin.

On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
> From: Colin Ian King 
> 
> 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