netdev - Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 12 Apr 2020 10:10:22 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Stable <stable@...r.kernel.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors

On Sun, Apr 12, 2020 at 2:16 AM Sasha Levin <sashal@...nel.org> wrote:

> [ Upstream commit 6783e8b29f636383af293a55336f036bc7ad5619 ]

Sasha,

This was pushed to net-next without a fixes tag, and there're probably
reasons for that.
As you can see the possible null deref is not even reproducible without another
patch which for itself was also net-next and not net one.

If a team is not pushing patch to net nor putting a fixes that, I
don't think it's correct
to go and pick that into stable and from there to customer production kernels.

Alsom, I am not sure what's the idea behind the auto-selection concept, e.g for
mlx5 the maintainer is specifically pointing which patches should go
to stable and
to what releases there and this is done with care and thinking ahead, why do we
want to add on that? and why this can be something which is just
automatic selection?

We have customers running production system with LTS 4.4.x and 4.9.y (along with
4.14.z and 4.19.w) kernels, we put lots of care thinking if/what
should go there, I don't
see a benefit from adding auto-selection, the converse.

Or.

> During transition to uplink representors the code responsible for
> initializing ethtool steering functionality wasn't added to representor
> init rx routine. This causes NULL pointer dereference during configuration
> of network flow classification rule with ethtool (only possible to
> reproduce with next commit in this series which registers necessary ethtool
> callbacks).

> Signed-off-by: Vlad Buslov <vladbu@...lanox.com>
> Reviewed-by: Roi Dayan <roid@...lanox.com>
> Signed-off-by: Sasha Levin <sashal@...nel.org>