netdev - Re: [patch net-next] devlink: remove reload failed checks in params get/set callbacks

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: <ZK6u8UFXjyD+a9R0@shredder>
Date: Wed, 12 Jul 2023 16:47:29 +0300
From: Ido Schimmel <idosch@...dia.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, kuba@...nel.org, pabeni@...hat.com,
	davem@...emloft.net, edumazet@...gle.com, moshe@...dia.com
Subject: Re: [patch net-next] devlink: remove reload failed checks in params
 get/set callbacks

On Wed, Jul 12, 2023 at 01:37:10PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@...dia.com>
> 
> The checks in question were introduced by
> commit 6b4db2e528f6 ("devlink: Fix use-after-free after a failed reload").
> 
> Back then, it was a possible fix. Alternative way to fix this was to
> make sure drivers register/unregister params in the code where it is
> ensured that the data accessed by params callbacks are available.
> But that was problematic as the list of params wes static durint

s/wes/was/
s/durint/during/

> devlink instance being registered.
> 
> Eventually this limitation was lifted and also the alternative fix
> (which also fixed another issue) was done for mlxsw by
> commit 74cbc3c03c82 ("mlxsw: spectrum_acl_tcam: Move devlink param to TCAM code").
> 
> The checks are no longer relevant, each driver should make sure to
> register/unregister params alongside with the data it touches. Remove
> the checks.
> 
> Signed-off-by: Jiri Pirko <jiri@...dia.com>

I don't see how we can hit the issue after 74cbc3c03c82 and any driver
that suffers from this issue should have already seen it after
7d7e9169a3ec, so this patch looks reasonable to me.

Reviewed-by: Ido Schimmel <idosch@...dia.com>