DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Praveen Shetty <praveen.shetty@intel.com>, <dev@dpdk.org>,
	<stable@dpdk.org>
Subject: Re: [PATCH v1] common/idpf: fix heap use after free error
Date: Thu, 23 Jan 2025 11:17:40 +0000	[thread overview]
Message-ID: <Z5IlVIh-3x-AZsKU@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <Z45ekTI7CC6V-J_t@bricha3-mobl1.ger.corp.intel.com>

On Mon, Jan 20, 2025 at 02:32:49PM +0000, Bruce Richardson wrote:
> On Mon, Jan 13, 2025 at 08:30:01AM -0800, Stephen Hemminger wrote:
> > On Mon, 13 Jan 2025 08:54:04 +0000
> > Praveen Shetty <praveen.shetty@intel.com> wrote:
> > 
> > > Heap use after free error is detected in AddressSanitizer while quitting
> > > the testpmd application.Issue is due to accessing the empty control
> > > queue in the idpf_ctlq_deinit function.idpf_ctlq_deinit function is called
> > > during the rte_eal_cleanup routine.
> > > This patch will fix this issue.
> > > 
> > > Fixes: fb4ac04e9bfa ("common/idpf: introduce common library")
> > > Cc: stable@dpdk.org
> > > 
> > > Signed-off-by: Praveen Shetty <praveen.shetty@intel.com>
> > 
> > This should not be needed. LIST_FOR_EACH_ENTRY_SAFE part, don't understand.
> 
> I would tend to agree. Is there an actual confirmed bug here? If so, then
> either our standard list macros are broken, or the code using them is doing
> something rather strange.
> 

I followed up on with with Praveen, and he went through the code and
possible solutions with me. The issue flagged by ASAN is correct, because
it turns out that the version of the _SAFE macro provided in this
particular driver is not actually safe! :-(

There are therefore two options to fixing this: 1) fix the macro/use a
different copy of the macro, or 2) rework the code as in this patch and drop
the macro. Copies of the driver in other OS use the style given in this patch,
so we will go with the second option. However, we will do a v2 to include
the removal of the bad macro, alongside fixing this. That should hopefully
prevent this issue from reoccurring.

Praveen, will review v2 when you send it.

/Bruce

  reply	other threads:[~2025-01-23 11:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-13  8:54 Praveen Shetty
2025-01-13 16:30 ` Stephen Hemminger
2025-01-20 14:32   ` Bruce Richardson
2025-01-23 11:17     ` Bruce Richardson [this message]
2025-01-23 11:43       ` David Marchand
2025-01-23 12:53         ` Bruce Richardson
2025-01-23 16:12         ` Stephen Hemminger

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=Z5IlVIh-3x-AZsKU@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=praveen.shetty@intel.com \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).