From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 51BFEA0C43; Wed, 20 Oct 2021 21:56:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0EDAB40E78; Wed, 20 Oct 2021 21:56:20 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 2591D40DF5 for ; Wed, 20 Oct 2021 21:56:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634759778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Gh6QyqyQvM5+Z5qgig69xF7PaxbXjqPlgyDUofDcrdw=; b=O+efxiwVypyUF0E06FyQGFFmJXJoVYKoGq0ESvuceL+OpTq+uEMB+oIOYpFDKGemUvwfAf ydzfZQOkt/vBb+GODG6sbJyDDi0jK+aY6OCu0vGgxYeyShnnOuuQX58iZCZT8dsyhN0kyy 2GWLiqaPp+zaL/b/qSHuKQjEeSUqVSw= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-450-0DO93wUuPRyzxv0xia8Vog-1; Wed, 20 Oct 2021 15:56:08 -0400 X-MC-Unique: 0DO93wUuPRyzxv0xia8Vog-1 Received: by mail-lf1-f70.google.com with SMTP id z29-20020a195e5d000000b003fd437f0e07so3428626lfi.20 for ; Wed, 20 Oct 2021 12:56:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gh6QyqyQvM5+Z5qgig69xF7PaxbXjqPlgyDUofDcrdw=; b=7RdKliXyhb8kPSo2j/MSn5SfFJc59s9RmDrV2HYlk8X9C0Hxm+Qvs1CgZiB8kJr0e3 eHJ6gnYGMQ91Mz/4oMGAKbxvxc/mBb/Q5bepofSdZ9LDrYgkZGdYEgBzUXNhCtQSIFaJ CbSGeJvHpV2DfjwtFhG/pHDZ3h8rSqaIMRGB4rRFRN35zJwAENtw+RktOGRnAE8qbMx9 cxy9ZIwzE+T3yVgOBROSZl0Bl6MsPAtLmLAd4oddZpHiQOFpSVI+HE/1txD5BS2U+d5e 1RnSu0IS+KB6SEttiex6j0TJv5BItx6HyIRYJMB+Y9lW0CQrOe6aMena3thI+Pw/eyiE 6NwQ== X-Gm-Message-State: AOAM532kOZyBhZpmccjzw8c3TA1pkTxorC4O6i1CfuhYP0Qu8A7YqR6N vrfn/ox4RKj0C0bbAdy+d6/OXiQStmlGw0DBum+crhFF/ZLjD14KqauzimikhAfgYjCG+sm0Pgy QtI8Cg+81cWWMWaUPa3g= X-Received: by 2002:a19:c514:: with SMTP id w20mr1208599lfe.265.1634759767263; Wed, 20 Oct 2021 12:56:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyrWfgTa7Ufy6nZ9LKI2IivEZsCnrO3OmI2axNnJlZtz7EOoBYMTfxsh01Epk76gzTWQkH/RRrMLdl3oeQYX6Y= X-Received: by 2002:a19:c514:: with SMTP id w20mr1208581lfe.265.1634759767082; Wed, 20 Oct 2021 12:56:07 -0700 (PDT) MIME-Version: 1.0 References: <1633728537-197824-1-git-send-email-vladimir.medvedkin@intel.com> In-Reply-To: <1633728537-197824-1-git-send-email-vladimir.medvedkin@intel.com> From: David Marchand Date: Wed, 20 Oct 2021 21:55:55 +0200 Message-ID: To: Vladimir Medvedkin Cc: dev , Bruce Richardson , alex@therouter.net, dpdk stable Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] lpm: fix buffer overflow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hello Vladimir, On Fri, Oct 8, 2021 at 11:29 PM Vladimir Medvedkin 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? > > Signed-off-by: Vladimir Medvedkin > --- > 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. > > /* Header of tbl8 */ > struct rte_lpm_tbl8_hdr { > -- > 2.7.4 > -- David Marchand