All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Bruce Richardson <bruce.richardson@intel.com>,
	<alex@therouter.net>, dpdk stable <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] lpm: fix buffer overflow
Date: Thu, 21 Oct 2021 19:15:24 +0200	[thread overview]
Message-ID: <988e9f4e-128b-bedc-4eb3-0eefb34745fc@intel.com> (raw)
In-Reply-To: <CAJFAV8xKz0CJWmcHDczQ1QKzBVX5=D-pfwHn3qBa_pJqn5OG5w@mail.gmail.com>

Hi David,

On 20/10/2021 21:55, David Marchand wrote:
> Hello Vladimir,
> 
> On Fri, Oct 8, 2021 at 11:29 PM Vladimir Medvedkin
> <vladimir.medvedkin@intel.com> wrote:
>>
>> This patch fixes buffer overflow reported by ASAN,
>> please reference https://bugs.dpdk.org/show_bug.cgi?id=819
>>
>> The rte_lpm6 keeps routing information for control plane purpose
>> inside the rte_hash table which uses rte_jhash() as a hash function.
>>  From the rte_jhash() documentation: If input key is not aligned to
>> four byte boundaries or a multiple of four bytes in length,
>> the memory region just after may be read (but not used in the
>> computation).
>> rte_lpm6 uses 17 bytes keys consisting of IPv6 address (16 bytes) +
>> depth (1 byte).
>>
>> This patch increases the size of the depth field up to uint32_t
>> and sets the alignment to 4 bytes.
>>
>> Bugzilla ID: 819
>> Fixes: 86b3b21952a8 ("lpm6: store rules in hash table")
>> Cc: alex@therouter.net
>> Cc: stable@dpdk.org
> 
> This change should be internal, and not breaking ABI, but are we sure
> we want to backport it?
> 

I think yes, I don't see any reason why we should not backport it.
Do you think we should not?

> 
>>
>> Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
>> ---
>>   lib/lpm/rte_lpm6.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/lpm/rte_lpm6.c b/lib/lpm/rte_lpm6.c
>> index 37baabb..d5e0918 100644
>> --- a/lib/lpm/rte_lpm6.c
>> +++ b/lib/lpm/rte_lpm6.c
>> @@ -80,8 +80,8 @@ struct rte_lpm6_rule {
>>   /** Rules tbl entry key. */
>>   struct rte_lpm6_rule_key {
>>          uint8_t ip[RTE_LPM6_IPV6_ADDR_SIZE]; /**< Rule IP address. */
>> -       uint8_t depth; /**< Rule depth. */
>> -};
>> +       uint32_t depth; /**< Rule depth. */
>> +} __rte_aligned(sizeof(uint32_t));
> 
> I would recommend doing the same than for hash tests: keep growing
> depth to 32bits, but no enforcement of alignment and add build check
> on structure size being sizeof(uin32_t) aligned.
> 

Agree, will send v2

> 
>>
>>   /* Header of tbl8 */
>>   struct rte_lpm_tbl8_hdr {
>> --
>> 2.7.4
>>
> 
> 

-- 
Regards,
Vladimir

  reply	other threads:[~2021-10-21 17:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-08 21:28 [dpdk-dev] [PATCH] lpm: fix buffer overflow Vladimir Medvedkin
2021-10-20 19:55 ` David Marchand
2021-10-21 17:15   ` Medvedkin, Vladimir [this message]
2021-10-21 17:15 ` [dpdk-dev] [PATCH v2] " Vladimir Medvedkin
2021-10-22  9:07   ` Bruce Richardson
2021-10-25 17:10     ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon

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=988e9f4e-128b-bedc-4eb3-0eefb34745fc@intel.com \
    --to=vladimir.medvedkin@intel.com \
    --cc=alex@therouter.net \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.