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 EA71BA0C43 for ; Wed, 20 Oct 2021 21:56:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DC4CF40142; Wed, 20 Oct 2021 21:56:18 +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 C3CF940142 for ; Wed, 20 Oct 2021 21:56:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634759776; 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=a/mMBp0qkvZIysnzT+x+9ntRTa9mPt+z694ugHkkUXFku5zp29Ii5oaDLKao9WrRJ/IyYX oC5kUXew7OZ9Wup3hpNwmUEimq4NxFy7er/SdLvRQxFx6tEGTuuQcOa8aGmyLDEJSOtY8K WJ8O0mIz2lU9Mg7G5qJqvWxFaSN+d4I= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-198-nx4hOxUZO0ap-1onDwOTiw-1; Wed, 20 Oct 2021 15:56:08 -0400 X-MC-Unique: nx4hOxUZO0ap-1onDwOTiw-1 Received: by mail-lj1-f198.google.com with SMTP id j13-20020a2e6e0d000000b0021101c034d5so2243648ljc.14 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=S3d3T7jN9aLiYKT64acJG9UYuY8nAycakiTbNCXMnG2XUNhiLCk+yJC8FUcPRRylcr Ic3dxr1LjXabMVuSTAO/6MHHm2s8VyDAkaB8ayhtRJmlw09Ym73g4g8/uTPZSMi8UDK7 qEKeBeNiKdZ7GFoaaaDflIP6IoAT62nVE8Fit0T8+sBWvVYksId05kU/5H6lKb/cvud3 aNRd9kXCL/FwD1Ukr94D/WbLCSLuon0Ylufevb8P3HNBTRs7YOD/TYqIgIkWAgfRGzE7 wW9OBjL1akMlO697f+MBsdwgIO5Iz8gEu7SMDHr64JJKrhPpVlFLBC366FCWglrlWwZC yDwg== X-Gm-Message-State: AOAM530Bmzf6iZuD+sUu6JdUtcA+i2mqu35hBgVYOOXM6DeV+WC354Hs cH44Iw/sNZ2XotkxxoJZoE93LtrsR+Pd32yE5vXGps5eoyXXZN1WZHZZalw/M22OqSgVelPRwcF wahQyZFtNA7aKVtX0yRN0lz0= X-Received: by 2002:a19:c514:: with SMTP id w20mr1208598lfe.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-stable] [PATCH] lpm: fix buffer overflow X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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