Re: [PATCH net 01/15] netfilter: nft_reject: prevent unbounded recursion in output hooks

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

On Tue, Nov 03, 2026 at 02:08:22PM +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.

Regarding the automated request, this series was primarily identified
through LLM-assisted analysis.
 
A summary of the discovery and triggering status follows:
 
Issues triggered and verified: Several issues were actively triggered
and confirmed via automated testing. This includes KASAN reports for
use-after-free and out-of-bounds access (patches 3, 4, 11), syzbot
reports for warnings and panics (patches 8 and 10), and a confirmed
sleeping function call in an atomic context (patch 14). Patch 12 was
identified via LLM and subsequently verified using a userspace ASan
harness.
 
Issues identified via LLM (Preventative):
The remaining patches were identified via LLM-assisted review. These
address edge cases to prevent future issues such as unbounded recursion
(patch 1), infinite loops (patch 2), stale connection growth (commit
5), chain depth exhaustion (patch 6), guard loss of recursive count
during reinjection (patch 7), NULL pointer dereferences (patch 9),
memory leaks (patch 13), and uninitialized stack data (patch 15).
 
This is a LLM answer to this automated message, with a few edits.

> 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.