netdev - Re: [PATCH 2/2] [v2] net/mlx5: fix possible stack overflows

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240220080624.GQ40273@kernel.org>
Date: Tue, 20 Feb 2024 08:06:24 +0000
From: Simon Horman <horms@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Saeed Mahameed <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>,
	Zhu Yanjun <yanjun.zhu@...ux.dev>, Arnd Bergmann <arnd@...db.de>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Yevgeny Kliteynik <kliteyn@...dia.com>,
	Alex Vesker <valex@...dia.com>, Hamdan Igbaria <hamdani@...dia.com>,
	netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] [v2] net/mlx5: fix possible stack overflows

On Mon, Feb 19, 2024 at 11:04:56AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
> 
> A couple of debug functions use a 512 byte temporary buffer and call another
> function that has another buffer of the same size, which in turn exceeds the
> usual warning limit for excessive stack usage:
> 
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_dbg.c:1073:1: error: stack frame size (1448) exceeds limit (1024) in 'dr_dump_start' [-Werror,-Wframe-larger-than]
> dr_dump_start(struct seq_file *file, loff_t *pos)
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_dbg.c:1009:1: error: stack frame size (1120) exceeds limit (1024) in 'dr_dump_domain' [-Werror,-Wframe-larger-than]
> dr_dump_domain(struct seq_file *file, struct mlx5dr_domain *dmn)
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_dbg.c:705:1: error: stack frame size (1104) exceeds limit (1024) in 'dr_dump_matcher_rx_tx' [-Werror,-Wframe-larger-than]
> dr_dump_matcher_rx_tx(struct seq_file *file, bool is_rx,
> 
> Rework these so that each of the various code paths only ever has one of
> these buffers in it, and exactly the functions that declare one have
> the 'noinline_for_stack' annotation that prevents them from all being
> inlined into the same caller.
> 
> Fixes: 917d1e799ddf ("net/mlx5: DR, Change SWS usage to debug fs seq_file interface")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> [v2] no changes, just based on patch 1/2 but can still be applied independently
> ---
>  .../mellanox/mlx5/core/steering/dr_dbg.c      | 82 +++++++++----------
>  1 file changed, 41 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_dbg.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_dbg.c
> index be7a8481d7d2..eae04f66b8f4 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_dbg.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_dbg.c
> @@ -205,12 +205,11 @@ dr_dump_hex_print(char hex[DR_HEX_SIZE], char *src, u32 size)
>  }
>  
>  static int
> -dr_dump_rule_action_mem(struct seq_file *file, const u64 rule_id,
> +dr_dump_rule_action_mem(struct seq_file *file, char *buff, const u64 rule_id,
>  			struct mlx5dr_rule_action_member *action_mem)
>  {
>  	struct mlx5dr_action *action = action_mem->action;
>  	const u64 action_id = DR_DBG_PTR_TO_ID(action);
> -	char buff[MLX5DR_DEBUG_DUMP_BUFF_LENGTH];
>  	u64 hit_tbl_ptr, miss_tbl_ptr;
>  	u32 hit_tbl_id, miss_tbl_id;
>  	int ret;

Hi Arnd,

With patch 1/2 in place this code goes on as:

	switch (action->action_type) {
	case DR_ACTION_TYP_DROP:
		memset(buff, 0, sizeof(buff));

buff is now a char * rather than an array of char.
siceof(buff) doesn't seem right here anymore.

Flagged by Coccinelle.