Re: [PATCH net-next 01/15] netfilter: disable br_netfilter in user namespaces

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi,

On Sun, Oct 18, 2026 at 01:03:17AM +0000, netdev-bot+sinfo@kernel.org wrote:
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.

Yes, this contains some low priority fixes as well as enhancements:

1) For the br_netfilter patch, existing limitations are known and
   issues keep popping from time to time, let's prepare for deprecation.

2) Found by Jakub in NIPA.

3) For the IPVS sync message overflow: found via manual code
   inspection. It is theoretical for modern kernels - the description
   notes it "can only happen in very old 2.6 kernels," so it was not
   triggered in any current production or test environment.

4 and 5) unclear if it was found in production, but it comes from
   third party software developer with realistic use-cases.

6) For the conntrack gc worker UaF: found via manual code inspection.
   It is described as "unlikely," so it is theoretical - not
   observed as a triggered crash or stack trace.

7) For the nf_tables chain types UaF on module removal: found via
   manual code inspection. The race window (module removal while RCU
   readers are active) makes it theoretical in practice; no stack trace
   or production report is referenced.

8 and 9) Simplify nft_exthdr tcp option parsing.

10) fixes a conntrack_vrf.sh selftest which has been seen to be
   reporting bogus issues.

11) was found via LLM that I am aware of.

12) is preparation work from Lorenzo Bianconi towards adding
    IPv4-over-IPv6 and vice-versa. 

This answer to this email has been assisted by LLM.

> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.