patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: David Marchand <david.marchand@redhat.com>
Cc: Bernard Iremonger <bernard.iremonger@intel.com>,
	dev <dev@dpdk.org>, dpdk stable <stable@dpdk.org>,
	Thomas Monjalon <thomas@monjalon.net>, "Singh\,
	Jasvinder" <jasvinder.singh@intel.com>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] librte_flow_classify: fix out-of-bounds access
Date: Tue, 30 Jul 2019 10:42:05 -0400	[thread overview]
Message-ID: <f7tpnlrlh36.fsf@dhcp-25.97.bos.redhat.com> (raw)
In-Reply-To: <CAJFAV8zvor_rp_XORKGsQSjyifpvsW1ESfeX24cYb7_X5+F29Q@mail.gmail.com> (David Marchand's message of "Mon, 29 Jul 2019 15:09:18 +0200")

David Marchand <david.marchand@redhat.com> writes:

> On Wed, Jul 10, 2019 at 11:49 PM Thomas Monjalon <thomas@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@dpdk.org
>> > Signed-off-by: Bernard Iremonger <bernard.iremonger@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?

  reply	other threads:[~2019-07-30 14:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-09 11:09 [dpdk-stable] " Bernard Iremonger
2019-07-10 21:48 ` [dpdk-stable] [dpdk-dev] " Thomas Monjalon
2019-07-29 13:09   ` David Marchand
2019-07-30 14:42     ` Aaron Conole [this message]
2019-07-30 14:48       ` Ferruh Yigit
2019-07-30 15:43         ` Aaron Conole
2019-07-30 16:55           ` Ferruh Yigit
2019-07-30 17:30             ` Aaron Conole
2019-07-30 16:18         ` Adrien Mazarguil
2019-07-30 16:35           ` Ferruh Yigit
2019-07-30 17:27             ` Aaron Conole
2019-07-30 18:51               ` Adrien Mazarguil
2019-07-30 14:44     ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f7tpnlrlh36.fsf@dhcp-25.97.bos.redhat.com \
    --to=aconole@redhat.com \
    --cc=bernard.iremonger@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jasvinder.singh@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).