All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Tariq Toukan <tariqt@nvidia.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
	Akiva Goldberger <agoldberger@nvidia.com>,
	Gal Pressman <gal@nvidia.com>, Kees Cook <kees@kernel.org>,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	Mark Bloch <mbloch@nvidia.com>, Moshe Shemesh <moshe@nvidia.com>,
	Saeed Mahameed <saeedm@nvidia.com>, Shay Drori <shayd@nvidia.com>
Subject: Re: [PATCH net] net/mlx5: FW tracer, clamp firmware-reported num_string_db
Date: Mon, 20 Jul 2026 12:10:27 +0300	[thread overview]
Message-ID: <20260720091027.GD110966@unreal> (raw)
In-Reply-To: <20260717072543.1241094-1-tariqt@nvidia.com>

On Fri, Jul 17, 2026 at 10:25:43AM +0300, Tariq Toukan wrote:
> From: Akiva Goldberger <agoldberger@nvidia.com>
> 
> mlx5_query_mtrc_caps() reads num_string_db from the MTRC capabilities
> register and uses it directly as a loop bound to populate the fixed-size
> base_address_out[STRINGS_DB_SECTIONS_NUM] and
> size_out[STRINGS_DB_SECTIONS_NUM] arrays in the tracer's str_db
> structure (STRINGS_DB_SECTIONS_NUM == 8).
> 
> The field is 4 bits wide, so firmware can report up to 15. A value
> greater than STRINGS_DB_SECTIONS_NUM makes the loop write past the end
> of those arrays, corrupting adjacent fields of the fw_tracer structure
> on the kernel heap. Clamp the firmware-reported value before it is used.
> 
> Fixes: f53aaa31cce7 ("net/mlx5: FW tracer, implement tracer logic")
> Signed-off-by: Akiva Goldberger <agoldberger@nvidia.com>
> Reviewed-by: Shay Drori <shayd@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
> index adcc73e2a5b3..404736c46adf 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
> @@ -64,6 +64,13 @@ static int mlx5_query_mtrc_caps(struct mlx5_fw_tracer *tracer)
>  	tracer->str_db.num_string_trace =
>  			MLX5_GET(mtrc_cap, out, num_string_trace);
>  	tracer->str_db.num_string_db = MLX5_GET(mtrc_cap, out, num_string_db);
> +	if (tracer->str_db.num_string_db > STRINGS_DB_SECTIONS_NUM) {
> +		mlx5_core_warn(dev,
> +			       "FWTracer: Firmware reports num_string_db (%u) > (%u), clamping\n",
> +			       tracer->str_db.num_string_db,
> +			       STRINGS_DB_SECTIONS_NUM);
> +		tracer->str_db.num_string_db = STRINGS_DB_SECTIONS_NUM;
> +	}

First, these lines are:

"tracer->str_db.num_string_db = min(tracer->str_db.num_string_db,
				    STRINGS_DB_SECTIONS_NUM);"

Second, this is a very naive approach to "securing" the system.
Everything originates from the firmware: registers, DMA, and data.
You cannot single out one field and claim the system is now "secure".

I am aware of another large vendor that added similar "clamping"
throughout their driver. That does not make the implementation correct
or particularly useful.

Thanks

>  	tracer->owner = !!MLX5_GET(mtrc_cap, out, trace_owner);
>  	tracer->str_db.loaded = false;
>  
> 
> base-commit: 3f1f755366687d051174739fb99f7d560202f60b
> -- 
> 2.44.0
> 
> 

      reply	other threads:[~2026-07-20  9:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17  7:25 [PATCH net] net/mlx5: FW tracer, clamp firmware-reported num_string_db Tariq Toukan
2026-07-20  9:10 ` Leon Romanovsky [this message]

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=20260720091027.GD110966@unreal \
    --to=leon@kernel.org \
    --cc=agoldberger@nvidia.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gal@nvidia.com \
    --cc=kees@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mbloch@nvidia.com \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeedm@nvidia.com \
    --cc=shayd@nvidia.com \
    --cc=tariqt@nvidia.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.