Re: [PATCH] netfilter: xt_realm: fix null-ptr-deref in realm_mt()

[Florian Westphal]

Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> On Wed, Apr 15, 2026 at 11:02:15AM +0200, Florian Westphal wrote:
> > Kito Xu (veritas501) <hxzene@xxxxxxxxx> wrote:
> > > realm_mt() unconditionally dereferences skb_dst(skb) without a NULL
> > > check. The xt_realm match registers with .family = NFPROTO_UNSPEC,
> > > making it available to all netfilter protocol families. Through the
> > > nftables compat layer (nft_compat), an unprivileged user inside a
> > > user/net namespace can load this match into a bridge-family chain.
> > 
> > I do not think this bug is related to nft_compat.
> > You can also use ebtables setsockopt api to request xt_realm, no?
> > 
> > > Fixes: ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions")
> > 
> > Looks correct.  Alternatively we could revert the xt_realm.c change.
> > But I don't have a strong opinion here, patch looks correct.
> 
> Maybe partial revert makes sense, since in ab4f21e6fb1c:
> 
> - xt_MARK: OK
> - xt_NOTRACK: OK
> - xt_comment: OK

Agree.

> - xt_mac: There is a better way to do this in bridge.

Right.

> - xt_owner, no sockets in bridge.

Output/postrouting maybe?

> - xt_physdev, which makes no sense in bridge, this is for br_netfilter
>   only.

Agree.

> - xt_realm (as already mentioned).
> That is, a partial revert of this patch for:
> 
> - xt_mac
> - xt_owner
> - xt_physdev
> - xt_realm

I'm ok with that too.