From: Saeed Mahameed <saeed@kernel.org>
To: Vadim Fedorenko <vadfed@meta.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>,
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 10:19:42 -0800 [thread overview]
Message-ID: <Y9qtPtTMvZUWtRso@x130> (raw)
In-Reply-To: <20230201122605.1350664-3-vadfed@meta.com>
On 01 Feb 04:26, Vadim Fedorenko wrote:
>Fifo indexes were not checked during pop operations and it leads to
>potential use-after-free when poping from empty queue. Such case was
>possible during re-sync action.
>
>There were out-of-order cqe spotted which lead to drain of the queue and
>use-after-free because of lack of fifo pointers check. Special check
>is added to avoid resync operation if SKB could not exist in the fifo
>because of OOO cqe (skb_id must be between consumer and producer index).
>
>Fixes: 58a518948f60 ("net/mlx5e: Add resiliency for PTP TX port timestamp")
>Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
>---
> .../net/ethernet/mellanox/mlx5/core/en/ptp.c | 23 ++++++++++++++-----
> .../net/ethernet/mellanox/mlx5/core/en/txrx.h | 4 +++-
> 2 files changed, 20 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c b/drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c
>index b72de2b520ec..5df726185192 100644
>--- a/drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c
>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c
>@@ -86,7 +86,7 @@ static bool mlx5e_ptp_ts_cqe_drop(struct mlx5e_ptpsq *ptpsq, u16 skb_cc, u16 skb
> return (ptpsq->ts_cqe_ctr_mask && (skb_cc != skb_id));
> }
>
>-static void mlx5e_ptp_skb_fifo_ts_cqe_resync(struct mlx5e_ptpsq *ptpsq, u16 skb_cc,
>+static bool mlx5e_ptp_skb_fifo_ts_cqe_resync(struct mlx5e_ptpsq *ptpsq, u16 skb_cc,
> u16 skb_id, int budget)
> {
> struct skb_shared_hwtstamps hwts = {};
>@@ -94,14 +94,23 @@ static void mlx5e_ptp_skb_fifo_ts_cqe_resync(struct mlx5e_ptpsq *ptpsq, u16 skb_
>
> ptpsq->cq_stats->resync_event++;
>
>- while (skb_cc != skb_id) {
>- skb = mlx5e_skb_fifo_pop(&ptpsq->skb_fifo);
>+ if (skb_cc > skb_id || PTP_WQE_CTR2IDX(ptpsq->skb_fifo_pc) < skb_id) {
To avoid returning boolean and add more functionality to this function,
I prefer to put this check in mlx5e_ptp_handle_ts_cqe(), see below.
>+ mlx5_core_err_rl(ptpsq->txqsq.mdev, "out-of-order ptp cqe\n");
it's better to add a counter for this, eg: ptpsq->cq_stats->ooo_cqe_drop++;
>+ return false;
>+ }
>+
>+ while (skb_cc != skb_id && (skb = mlx5e_skb_fifo_pop(&ptpsq->skb_fifo))) {
> hwts.hwtstamp = mlx5e_skb_cb_get_hwts(skb)->cqe_hwtstamp;
> skb_tstamp_tx(skb, &hwts);
> ptpsq->cq_stats->resync_cqe++;
> napi_consume_skb(skb, budget);
> skb_cc = PTP_WQE_CTR2IDX(ptpsq->skb_fifo_cc);
> }
>+
>+ if (!skb)
>+ return false;
>+
>+ return true;
> }
>
> static void mlx5e_ptp_handle_ts_cqe(struct mlx5e_ptpsq *ptpsq,
>@@ -111,7 +120,7 @@ static void mlx5e_ptp_handle_ts_cqe(struct mlx5e_ptpsq *ptpsq,
> u16 skb_id = PTP_WQE_CTR2IDX(be16_to_cpu(cqe->wqe_counter));
> u16 skb_cc = PTP_WQE_CTR2IDX(ptpsq->skb_fifo_cc);
> struct mlx5e_txqsq *sq = &ptpsq->txqsq;
>- struct sk_buff *skb;
>+ struct sk_buff *skb = NULL;
> ktime_t hwtstamp;
>
> if (unlikely(MLX5E_RX_ERR_CQE(cqe))) {
>@@ -120,8 +129,10 @@ static void mlx5e_ptp_handle_ts_cqe(struct mlx5e_ptpsq *ptpsq,
> goto out;
> }
>
>- if (mlx5e_ptp_ts_cqe_drop(ptpsq, skb_cc, skb_id))
>- mlx5e_ptp_skb_fifo_ts_cqe_resync(ptpsq, skb_cc, skb_id, budget);
you can check here:
/* ignore ooo cqe as it was already handled by a previous resync */
if (ooo_cqe(cqe))
return;
>+ if (mlx5e_ptp_ts_cqe_drop(ptpsq, skb_cc, skb_id) &&
>+ !mlx5e_ptp_skb_fifo_ts_cqe_resync(ptpsq, skb_cc, skb_id, budget)) {
>+ goto out;
>+ }
>
> skb = mlx5e_skb_fifo_pop(&ptpsq->skb_fifo);
> hwtstamp = mlx5e_cqe_ts_to_ns(sq->ptp_cyc2time, sq->clock, get_cqe_ts(cqe));
>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/txrx.h b/drivers/net/ethernet/mellanox/mlx5/core/en/txrx.h
>index d5afad368a69..e599b86d94b5 100644
>--- a/drivers/net/ethernet/mellanox/mlx5/core/en/txrx.h
>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/txrx.h
>@@ -295,13 +295,15 @@ static inline
> void mlx5e_skb_fifo_push(struct mlx5e_skb_fifo *fifo, struct sk_buff *skb)
> {
> struct sk_buff **skb_item = mlx5e_skb_fifo_get(fifo, (*fifo->pc)++);
>-
redundant change.
> *skb_item = skb;
> }
>
> static inline
> struct sk_buff *mlx5e_skb_fifo_pop(struct mlx5e_skb_fifo *fifo)
> {
>+ if (*fifo->pc == *fifo->cc)
>+ return NULL;
>+
I think this won't be necessary if you check for ooo early on
mlx5e_ptp_handle_ts_cqe() like i suggested above.
> return *mlx5e_skb_fifo_get(fifo, (*fifo->cc)++);
> }
>
>--
>2.30.2
>
next prev parent reply other threads:[~2023-02-01 18:19 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 [this message]
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
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=Y9qtPtTMvZUWtRso@x130 \
--to=saeed@kernel.org \
--cc=gal@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rrameshbabu@nvidia.com \
--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).