netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Saeed Mahameed <saeed@kernel.org>
Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	Vadim Fedorenko <vadfed@meta.com>,
	Rahul Rameshbabu <rrameshbabu@nvidia.com>,
	Tariq Toukan <ttoukan.linux@gmail.com>,
	Gal Pressman <gal@nvidia.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net v4 2/2] mlx5: fix possible ptp queue fifo use-after-free
Date: Wed, 1 Feb 2023 19:01:15 -0800	[thread overview]
Message-ID: <20230201190115.48fcebf0@kernel.org> (raw)
In-Reply-To: <Y9r4UHZUUAdYdTPp@x130>

On Wed, 1 Feb 2023 15:40:00 -0800 Saeed Mahameed wrote:
> >And again the only concern here is that we don't have any checks 
> >whether FIFO has anything to pop before actually poping the value. 
> >That can easily bring use-after-free in the futuee, especially because 
> >the function is not ptp specific and is already used for other fifos. 
> >I can add unlikely() for this check if it helps, but I would like to 
> >have this check in the code.
> 
> you shouldn't access the fifo if by design it's guaranteed nothing is there.
> We don't build for a future/fool proof code, the fifo is only accessed
> when we know there's something there by design, this is not a general
> purpose fifo, it's a fifo used by mlx5 ordered cqs.. 

The check for fifo being empty seems 100% sane to me. You can put 
a WARN_ON_ONCE() on it if you believe it can never happen. But the
cost of dealing with random double frees is much higher than a single
conditional on not-so-fast path.

> According to your logic, kfree should also check for double free.. ? :) 

I reckon we'd happily make kfree check for double free if there was
an efficient way of doing that. Various large companies build their
production kernels with KFENCE enabled, AFAIK.

  parent reply	other threads:[~2023-02-02  3:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 12:26 [PATCH net v4 0/2] mlx5: ptp fifo bugfixes Vadim Fedorenko
2023-02-01 12:26 ` [PATCH net v4 1/2] mlx5: fix skb leak while fifo resync and push Vadim Fedorenko
2023-02-01 12:26 ` [PATCH net v4 2/2] mlx5: fix possible ptp queue fifo use-after-free Vadim Fedorenko
2023-02-01 18:19   ` Saeed Mahameed
2023-02-01 21:36     ` Vadim Fedorenko
2023-02-01 23:40       ` Saeed Mahameed
2023-02-02  1:34         ` Vadim Fedorenko
2023-02-02  3:01         ` Jakub Kicinski [this message]
2023-02-02  3:08   ` Jakub Kicinski
2023-02-02 11:48     ` Vadim Fedorenko

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=20230201190115.48fcebf0@kernel.org \
    --to=kuba@kernel.org \
    --cc=gal@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=rrameshbabu@nvidia.com \
    --cc=saeed@kernel.org \
    --cc=ttoukan.linux@gmail.com \
    --cc=vadfed@meta.com \
    --cc=vadim.fedorenko@linux.dev \
    /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).