Re: [BUG] netfilter: unbounded nftables reject recursion on inet OUTPUT

[Florian Westphal <fw@strlen.de>]

Yu Junzhe <junzheyu1@gmail.com> wrote:
> I am reporting unbounded hook recursion on inet OUTPUT: an nftables
> output chain that does a TCP flags payload-set followed by
> "reject with tcp reset" makes nf_send_reset() re-enter the same
> NF_INET_LOCAL_OUT hook until the kernel stack is exhausted.
>
> Summary
> =======
> 
> nft_reject_inet_eval() calls nf_send_reset(), which builds a RST skb
> and transmits it with ip_local_out(). That walks the same OUTPUT
> hooks again.

Can you send us a patch for this?

> The only loop guard in nf_reject_ip_tcphdr_get() is the packet-content
> check:
> 
>   /* No RST for RST. */
>   if (oth->rst)
>           return NULL;
> 
> If a payload-set runs first and rewrites the TCP flags byte to SYN,
> that guard never sees RST, so another RST is generated. The cycle is:
> 
>   nft_do_chain
>     -> nft_reject_inet_eval
>       -> nf_send_reset
>         -> ip_local_out
>           -> nf_hook_slow
>             -> nft_do_chain
> 
> nft_reject_inet_validate() allows NF_INET_LOCAL_OUT.
> 
> This is a legal nftables configuration (payload set + reject with tcp
> reset on an output base chain), including with CAP_NET_ADMIN in a
> network namespace. I do not claim privilege escalation; the result we
> see is local DoS (stack overflow, then panic).
> 
> I am aware of the existing recursion bound on the netdev fwd/neigh
> xmit path. nf_send_reset() via ip_local_out() does not use it.

Tell your coding assistant to move it to include/net/netfilter/nf_recursion.h,
add that include to the existing users, then extend all reset functions
(icmp and tcp reset) to use those helpers.