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]
Date: Mon, 19 Feb 2024 09:05:44 +0000
From: Hamdan Agbariya <hamdani@...dia.com>
To: Zhu Yanjun <yanjun.zhu@...ux.dev>, Arnd Bergmann <arnd@...db.de>, Arnd
 Bergmann <arnd@...nel.org>, Saeed Mahameed <saeedm@...dia.com>, Leon
 Romanovsky <leon@...nel.org>
CC: "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>, Netdev <netdev@...r.kernel.org>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] net/mlx5: fix possible stack overflows

> 在 2024/2/15 16:03, Arnd Bergmann 写道:
> > On Thu, Feb 15, 2024, at 01:18, Zhu Yanjun wrote:
> >> 在 2024/2/13 18:08, Arnd Bergmann 写道:
> >>>    static int
> >>> -dr_dump_rule_rx_tx(struct seq_file *file, struct mlx5dr_rule_rx_tx
> >>> *rule_rx_tx,
> >>> +dr_dump_rule_rx_tx(struct seq_file *file, char *buff,
> >>> +              struct mlx5dr_rule_rx_tx *rule_rx_tx,
> >>>                bool is_rx, const u64 rule_id, u8 format_ver)
> >>>    {
> >>>     struct mlx5dr_ste *ste_arr[DR_RULE_MAX_STES +
> >>> DR_ACTION_MAX_STES]; @@ -533,7 +532,7 @@
> dr_dump_rule_rx_tx(struct seq_file *file, struct mlx5dr_rule_rx_tx
> *rule_rx_tx,
> >>>             return 0;
> >>>
> >>>     while (i--) {
> >>> -           ret = dr_dump_rule_mem(file, ste_arr[i], is_rx, rule_id,
> >> Before buff is reused, I am not sure whether buff should be firstly
> >> zeroed or not.
> > I don't see why it would, but if you want to zero it, that would be a
> > separate patch that is already needed on the existing code, which
> > never zeroes its buffers.
> 
> Sure. I agree with you. In the existing code, the buffers are not zeroed.
> 
> But to a buffer which is used for several times, it is good to zero it before it is
> used again.
> 
> Can you add a new commit with the following?
> 
> 1). Zero the buffers in the existing code
> 

No need to zero the buffers, as it does not have any necessity and it will only affect performance.
Thanks,
Hamdan




> 2). Add the zero functionality to your patch
> 
>  From my perspective, it is good to the whole commit.
> 
> Please Jason and Leon comment on this.
> 
> Thanks,
> 
> Zhu Yanjun
> 
> >
> >      Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ