CVE-2026-72072: net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: macsec: fix use-after-free of metadatadst on RX SC delete

When an offloaded MACsec RX SC is deleted, macsecdelrxscctx() freed the per-SC metadatadst with metadatadstfree(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5emacsecoffloadhandlerxskb() looks up the SC under rcureadlock() via xaload(), takes a reference with dsthold() and attaches the dst to the skb with skbdstset(). A reader that already obtained the rxsc pointer can race with the delete path and operate on freed memory.

Fix the owner side by dropping the reference with dstrelease() instead of freeing unconditionally, and convert the RX datapath to dstholdsafe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken.

mlx5emacsecaddrxsc() also published scxarrayelement via xaalloc() before rxsc->mddst was allocated and initialised, so a datapath reader that looked the SC up by fsid could observe rxsc with mddst still NULL or, on weakly-ordered architectures, a non-NULL mddst pointer whose contents were not yet visible. NULL-check the xaload() result and mddst on the datapath, and reorder addrxsc() so the xaalloc() publish happens only after mddst is fully initialised; the xarray RCU publish then pairs with the rcureadlock()/xaload() in the datapath.

Note: macsecdelrxscctx() also kfree()s rxsc->scxarrayelement without an RCU grace period while the same datapath reads it under rcureadlock(); that is a separate pre-existing issue left to a follow-up patch.

Found by 0sec automated security-research tooling (https://0sec.ai).