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 5EF91A0C4C for ; Thu, 14 Oct 2021 10:34:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4E96E40041; Thu, 14 Oct 2021 10:34:44 +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 3091D40041 for ; Thu, 14 Oct 2021 10:34:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634200482; 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=UngY+p+jFnU8QX1YacV7pugy+4w39RTMbIf/8FXAszg=; b=Sg988sR+p3MvVI1IY1e5l+8fTy08gu4fQi+scVKSx3HYeIozxv3Qbzg82A5Xsrm/WrsMDn 2In4SsB5MpBJo/xNyIAYSAopDa6H7FUY2y5sv6RDVeVmZU845+OgA8YQXYfaHs6Td2ZfFz CG5UCtS4ZvuMFF0Javom2Wa+C09m/48= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-98-2l9_7WpZPPiN0pEuNf9vDQ-1; Thu, 14 Oct 2021 04:34:35 -0400 X-MC-Unique: 2l9_7WpZPPiN0pEuNf9vDQ-1 Received: by mail-lf1-f72.google.com with SMTP id z29-20020a195e5d000000b003fd437f0e07so3796443lfi.20 for ; Thu, 14 Oct 2021 01:34:35 -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=UngY+p+jFnU8QX1YacV7pugy+4w39RTMbIf/8FXAszg=; b=5YLSsMxEiLD0cWGynLFgZBOncLwiM46uCuK38T0ooIuSSjH5J9TdLJzVJ7K7cRZW3x UgA+AMnctGzErQCN5sTa5co5myj22ZXEK7TMe++o2b51THq+C1DJ1FdRJLn7LAnuBRK8 q5E0NxnGT9tv/0GqaFN0qG0Qz8us6/8cwOhk3lhlZgOUhkMyuHgb4LPN1Qx/pRxVXg4K Gxout4yuBcZMvoxKiOFExmni0rsYAXVoROyHDPNoIIbRvamfOonrgfSzN0nSwPhDmsuA Qwn+VgJ6iShaP1Iu6i0BxzWWDLR79fPuYGqkfRjknvVv5wN+nDNWs8Wqg2BcgXuyfWY4 1UiQ== X-Gm-Message-State: AOAM533WiB2riaHfDHXtI7Nr3AjghczLVVBHo3vDJkwhftl3R2XGEA5z vvm4wJ3GF09e1NVkn2XiTTHNopis3Labi6t8OQD/jWdNqpzkMBM/zKNJQ331bZy+xqBF9rkbz99 s3v94pp+aIMsA+FFHxIpgyDY= X-Received: by 2002:a05:6512:31c3:: with SMTP id j3mr3941525lfe.217.1634200474206; Thu, 14 Oct 2021 01:34:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGTJ1XerKKrEp0IUZI0WrANhkdQaoJ4+MekZesuEuAHmnw7ViJF5PjLubORFKU2fNEiBWyPOlMdYlgGBcwSTA= X-Received: by 2002:a05:6512:31c3:: with SMTP id j3mr3941492lfe.217.1634200473812; Thu, 14 Oct 2021 01:34:33 -0700 (PDT) MIME-Version: 1.0 References: <1633728526-197782-1-git-send-email-vladimir.medvedkin@intel.com> <1634153265-193315-1-git-send-email-vladimir.medvedkin@intel.com> In-Reply-To: <1634153265-193315-1-git-send-email-vladimir.medvedkin@intel.com> From: David Marchand Date: Thu, 14 Oct 2021 10:34:22 +0200 Message-ID: To: Vladimir Medvedkin Cc: dev , "Wang, Yipeng1" , "Gobriel, Sameh" , Bruce Richardson , 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 v2] test/hash: 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" On Wed, Oct 13, 2021 at 9:28 PM Vladimir Medvedkin wrote: > > This patch fixes buffer overflow reported by ASAN, > please reference https://bugs.dpdk.org/show_bug.cgi?id=818 > > Some tests for the rte_hash table use the rte_jhash_32b() as > the hash function. This hash function interprets the length > argument in units of 4 bytes. > > This patch divides configured key length by 4 in cases when > rte_jhash_32b() is used. > > For some tests rte_jhash() is used with keys of length not > a multiple of 4 bytes. 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). > > This patch increases the size of the proto field of the > flow_key struct up to uint32_t and sets the alignment to 4 bytes. > > Bugzilla ID: 818 > Fixes: af75078fece3 ("first public release") > Cc: stable@dpdk.org > > Signed-off-by: Vladimir Medvedkin > --- > app/test/test_hash.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/app/test/test_hash.c b/app/test/test_hash.c > index bd4d0cb..e3f2d29 100644 > --- a/app/test/test_hash.c > +++ b/app/test/test_hash.c > @@ -80,8 +80,8 @@ struct flow_key { > uint32_t ip_dst; > uint16_t port_src; > uint16_t port_dst; > - uint8_t proto; > -} __rte_packed; > + uint32_t proto; > +} __rte_packed __rte_aligned(sizeof(uint32_t)); If in the future, we add a field not multiple of sizeof(uint32_t), there will be some padding at the end of the structure. I *think* holes and padding content is undefined for initialized objects (though maybe things could be different with objects in .data ?). That's probably something to confirm. If this is the case, the hash function would consider random data. I think growing the proto field to uint32_t like you did is the right fix since the whole structure is now naturally uint32_t aligned. But I would remove the aligned attribute and prefer RTE_BUILD_BUG(sizeof(struct flow_key) % sizeof(sizeof(uint32_t)) != 0). Maybe add a comment to explain we keep the packed attribute to avoid holes with potentially undefined content in the middle of this struct. -- David Marchand