From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by dpdk.org (Postfix) with ESMTP id 53AE1B3FF for ; Sun, 22 Feb 2015 19:47:37 +0100 (CET) Received: by mail-oi0-f51.google.com with SMTP id g201so10284293oib.10 for ; Sun, 22 Feb 2015 10:47:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qJ1tKgFV8azXnV6f3y9+qJLIJKP2LO0NIO6tBoJ+TAE=; b=GMjnXJOOaM3e/QHVeHZffUqS+owiOnsr6+h5OJqb6E49WKFdZ02W3id/flRbfOQ9Dv ajQAZw5I3nAgR1UMOt5kpmwsZGibjPtD+J5ji2gZjcsBzhcQ4tPxwtbwzUepCg5vtL50 xE8QHci3ld3Erp55JIp5oHKR83+whrZWzppk23oXzSo8qnIz5T/jhcQl2Vk85edcOoKy 3toLJq89q/bjAZTIL8VOlyv0h9Q7pf3fmvC9abiQKrSO3Dk7zjMRJ/Yng/TW8rH/iL2Y 6TKKiXaqu6hEAlSV1wALSqsFVeeGD4CVw9BFWDJB+c8Ls/ZD6mmkZUkJ4CYTDwHTFLml P6Rg== X-Gm-Message-State: ALoCoQm7y3AwhaAMJhcOey9He/UlBaaPhSYx34cfr6oSjQ0FujrJwd7BaSVZNE3p2PRAkxeth8ij MIME-Version: 1.0 X-Received: by 10.182.81.98 with SMTP id z2mr5190814obx.35.1424630856730; Sun, 22 Feb 2015 10:47:36 -0800 (PST) Received: by 10.60.80.233 with HTTP; Sun, 22 Feb 2015 10:47:36 -0800 (PST) X-Originating-IP: [195.16.110.2] In-Reply-To: <19E2A698-96BB-4CFE-9BCE-50AFB815D24B@intel.com> References: <1424438206-29526-1-git-send-email-iryzhov@nfware.com> <19E2A698-96BB-4CFE-9BCE-50AFB815D24B@intel.com> Date: Sun, 22 Feb 2015 22:47:36 +0400 Message-ID: From: Igor Ryzhov To: "Richardson, Bruce" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] lpm: fix overflow issue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 18:47:37 -0000 Great. The easiest way to reproduce the issue is to fill LPM table with rules using only one depth and try to add another one rule with same depth. Rule will be successfully added and memory will be corrupted. =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 22 =D1= =84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2015 =D0=B3. =D0=BF=D0=BE=D0=BB=D1= =8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Richardson, Bruce =D0= =BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > Sorry I missed this Friday. I'll look at it shortly. > > > > On 21 Feb 2015, at 22:56, Igor Ryzhov > >> wrote: > > Hello again. Will anybody review this patch? > This is really critical issue, because it can lead to memory corruption > and break any program using LPM. > > CCing this to Bruce Richardson, because he is maintainer of LPM. > > Regards, > Igor Ryzhov > > On Fri, Feb 20, 2015 at 4:16 PM, Igor Ryzhov >> wrote: > LPM table overflow may occur if table is full and added rule has the > biggest depth that already have some rules. > > Signed-off-by: Igor Ryzhov iryzhov@nfware.com >> > --- > lib/librte_lpm/rte_lpm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c > index 983e04b..cc51210 100644 > --- a/lib/librte_lpm/rte_lpm.c > +++ b/lib/librte_lpm/rte_lpm.c > @@ -298,6 +298,9 @@ rule_add(struct rte_lpm *lpm, uint32_t ip_masked, > uint8_t depth, > return rule_index; > } > } > + > + if (rule_index =3D=3D lpm->max_rules) > + return -ENOSPC; > } else { > /* Calculate the position in which the rule will be > stored. */ > rule_index =3D 0; > -- > 1.9.3 (Apple Git-50) > > > > > -- > Regards, > Igor Ryzhov >