Re: [PATCH net 1/1] inet_diag: cap bytecode filter complexity

[zihan xi]

On Mon, Sep 7, 2026 at 10:11 PM Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
>
> On Mon, Sep 7, 2026 at 3:53 PM Zihan Xi <zihanx@xxxxxxxxxx> wrote:
> >
> > inet_diag dumps run request-supplied bytecode through inet_diag_bc_sk()
> > while walking TCP, UDP and MPTCP hash buckets under their bucket locks.
> > The auditor currently accepts an arbitrarily long program, so a dump
> > can spend unbounded time in that locked section.
> >
> > That fact is already present at the git epoch: tcpdiag_bc_audit() had
> > no op cap, and tcpdiag_dump() ran the bytecode under the listener and
> > ehash locks. Later inet_diag extraction only moved the same code.
> >
> > ss(8) filters only need a handful of compare/host/mark operations.
> > Reject programs with more than 64 ops in inet_diag_bc_audit() so TCP,
> > UDP and MPTCP dumps share the same limit. 64 is a policy cap above a
> > normal ss(8) filter, not a lock-hold budget.
> >
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Reported-by: Vega <vega@xxxxxxxxxx>
> > Assisted-by: LLM
> > Co-developed-by: Luxing Yin <root@xxxxxxxxxx>
> > Signed-off-by: Luxing Yin <root@xxxxxxxxxx>
> > Signed-off-by: Zihan Xi <zihanx@xxxxxxxxxx>
> > ---
> >  net/ipv4/inet_diag.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
> > index 34b77aa87d0a4..1ca528cd3e72b 100644
> > --- a/net/ipv4/inet_diag.c
> > +++ b/net/ipv4/inet_diag.c
> > @@ -725,6 +725,12 @@ static bool valid_cgroupcond(const struct inet_diag_bc_op *op, int len,
> >  }
> >  #endif
> >
> > +/* ss(8) filters only need a handful of compare/host/mark ops.
> > + * Bound the program so dump walks cannot run an arbitrarily long
> > + * bytecode sequence under the socket hash bucket locks.
> > + */
> > +#define INET_DIAG_BC_MAX_OPS 64
>
> This is unacceptable.
>
> I am tempted to say that any hash bucket with more than 1000 sockets
> in it is a problem, not only for inet_diag.
>
> Since there is no soft lockup, this really looks like an attempt by AI
> to break legitimate Linux uses.
> (Or slow down as your prior versions did)

Thanks for the feedback.

We will drop this series.

Best regards,
Zihan