[dpdk-stable] [dpdk-dev] [PATCH] librte_flow_classify: fix out-of-bounds access

[Ferruh Yigit]

On 7/30/2019 3:42 PM, Aaron Conole wrote:
> David Marchand <david.marchand at redhat.com> writes:
> 
>> On Wed, Jul 10, 2019 at 11:49 PM Thomas Monjalon <thomas at monjalon.net> wrote:
>>>
>>> 09/07/2019 13:09, Bernard Iremonger:
>>>> This patch fixes the out-of-bounds coverity issue by removing the
>>>> offending line of code at line 107 in rte_flow_classify_parse.c
>>>> which is never executed.
>>>>
>>>> Coverity issue: 343454
>>>>
>>>> Fixes: be41ac2a330f ("flow_classify: introduce flow classify library")
>>>> Cc: stable at dpdk.org
>>>> Signed-off-by: Bernard Iremonger <bernard.iremonger at intel.com>
>>>
>>> Applied, thanks
>>
>> We have a segfault in the unit tests since this patch.
> 
> I think this patch is still correct.  The issue is in the semantic of
> the flow classify pattern.  It *MUST* always have a valid end marker,
> but the test passes an invalid end marker.  This causes the bounds to
> exceed.
> 
> So, it would be best to fix it, either by having a "failure" on unknown
> markers (f.e. -1), or by passing a length around.  However, the crash
> should be expected.  The fact that the previous code was also incorrect
> and resulted in no segfault is pure luck.
> 
> See rte_flow_classify_parse.c:80 and test_flow_classify.c:387
> 
> I would be in favor of passing the lengths of the two arrays to these
> APIs.  That would let us still make use of the markers (for valid
> construction), but also let us reason about lengths in a sane way.
> 
> WDYT?
> 

+1, I also just replied with something very similar.

With current API the testcase is wrong, and it will crash, also the invalid
action one has exact same problem.

The API can be updated as you suggested, with a length field and testcases can
be added back.

What worries me more is the rte_flow, which uses same arguments, and open to
same errors, should we consider updating rte_flow APIs to have lengths values too?