On Jun 01, Florian Westphal wrote: > Another sashiko drive-by report. TL;DR, do you need to apply this > pattern in your driver? > > - metadata_dst_free(priv->md); > + dst_release(&priv->md->dst); > > Affects: > drivers/net/ethernet/airoha/airoha_eth.c > drivers/net/ethernet/intel/ice/ice_eswitch.c > drivers/net/ethernet/mediatek/mtk_eth_soc.c > drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c > > Long version: > https://sashiko.dev/#/patchset/20260527135751.1031891-1-tristmd%40gmail.com > > This isn't a bug introduced by this patch, but looking at this fix, do > other callers of metadata_dst_free() suffer from the same use-after-free > vulnerability? > In drivers like ice_eswitch and mlx5 MACsec, a metadata_dst is allocated > and references are taken on it via dst_hold() when packets are processed > (for example, via skb_dst_set()). > However, on their teardown paths, these drivers call metadata_dst_free(), > which unconditionally frees the memory without checking the reference count. > If packets holding these references are queued (like in a netem qdisc) > during teardown, does the memory get freed prematurely, causing a > use-after-free when the networking stack eventually calls dst_release() > on the dequeued packets?
Hi Florian, For airoha_eth and mtk_eth_soc I think the issue is less severe since we destroy the metadata after running unregister_netdev() (that executes synchronize_net()), but I guess it is better to fix the problem. I will post a fix for them. Regards, Lorenzo
signature.asc
Description: PGP signature
