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

[Pablo Neira Ayuso]

On Wed, Apr 15, 2026 at 11:44:07AM +0200, Florian Westphal wrote:
> 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.

For the record, this patch has been replaced by:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/20260415113334.61008-1-pablo@xxxxxxxxxxxxx/