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: <df36633f-05c4-471e-93ca-f890de670565@I-love.SAKURA.ne.jp>
Date: Tue, 27 Jan 2026 00:57:58 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Leon Romanovsky <leon@...nel.org>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        Sabrina Dubroca <sd@...asysnail.net>
Cc: Boris Pismenny <borisp@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Westphal <fw@...len.de>,
        Kristian Evensen <kristian.evensen@...il.com>,
        Raed Salem <raeds@...lanox.com>, Raed Salem <raeds@...dia.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Yossi Kuperman <yossiku@...lanox.com>,
        Network Development <netdev@...r.kernel.org>,
        Aviad Yehezkel <aviadye@...dia.com>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH] xfrm: force flush upon NETDEV_UNREGISTER event

On 2026/01/26 20:07, Leon Romanovsky wrote:
> Steffen, Tetsuo
> 
> If by "HW people" you mean me, we always set NETIF_F_HW_ESP when adding
> the .xfrm_dev_*_add() callbacks.
> 
>   1334 void mlx5e_ipsec_build_netdev(struct mlx5e_priv *priv)
>   1335 {
>   1336         struct mlx5_core_dev *mdev = priv->mdev;
>   1337         struct net_device *netdev = priv->netdev;
>   1338
>   1339         if (!mlx5_ipsec_device_caps(mdev))
>   1340                 return;
>   1341
>   1342         mlx5_core_info(mdev,
>   1343                        "mlx5e: IPSec ESP acceleration enabled\n");
>   1344
>   1345         netdev->xfrmdev_ops = &mlx5e_ipsec_xfrmdev_ops;
>   1346         netdev->features |= NETIF_F_HW_ESP;
>   1347         netdev->hw_enc_features |= NETIF_F_HW_ESP;
> 
> So we are left with two possibilities: either the device registered XFRM
> ops without setting NETIF_F_HW_ESP, or netdev->features was modified
> without clearing the xfrmdev_ops pointer.

I didn't know that netdev->features can be updated via "struct net_device_ops"->
ndo_set_features() callback using "ethtool -K".

Since netdev->features is not "constant after creation", how can
the (dev->features & NETIF_F_HW_ESP) check in xfrm_dev_down() make sense?

Sabrina Dubroca commented that the current behavior ("ignore NETIF_F_HW_ESP and
call xdo_dev_state_add for new states anyway") has been established for multiple
years. Then, I think that we can't count on NETIF_F_HW_ESP bit. I think that
we can't guarantee that dev_put() from xfrm_dev_down() will be called unless
https://lkml.kernel.org/r/447378de-3cc9-44f5-872e-a1fc477f591e@I-love.SAKURA.ne.jp
is applied.

> Which device is triggering the syzcaller crash?

In a off-list mail, Leon Romanovsky commented that netdevsim0 device did not
clear its xfrmdev_ops pointer when NETIF_F_HW_ESP bit was removed.

Indeed, it seems that nsim_set_features() does not update xfrmdev_ops pointer
when toggling esp-hw-offload feature, but my question above remains regardless of
xfrmdev_ops pointer.

[  185.475627] [   T1489] nsim_set_features dev->xfrmdev_ops=000000000f684dab dev->features=41800008001c869 features=41000008001c869
[  237.302143] [   T1510] nsim_set_features dev->xfrmdev_ops=000000000f684dab dev->features=41000008001c869 features=41800008001c869
[  258.573477] [   T1531] nsim_set_features dev->xfrmdev_ops=000000000f684dab dev->features=41800008001c869 features=41c00008001c869
[  263.853173] [   T1571] nsim_set_features dev->xfrmdev_ops=000000000f684dab dev->features=41c00008001c869 features=41800008001c869
[  295.907167] [   T1612] nsim_set_features dev->xfrmdev_ops=000000000f684dab dev->features=41800008001c869 features=41c00008001c869


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ