Re: [PATCH net 0/2] tcp: diag: fix unbounded bucket lock hold in diag dump paths

On Fri, Jul 31, 2026 at 3:58=E2=80=AFAM Kuniyuki Iwashima <[email protected]=
m> wrote:
>
> On Wed, Jul 29, 2026 at 1:29=E2=80=AFPM Zihan Xi <[email protected]> wrot=
e:
> >
> > Hi Linux kernel maintainers,
> >
> > We found and validated a issue in net/ipv4/tcp_diag.c and
> > net/mptcp/mptcp_diag.c. The bug is reachable by a
> > non-root user via user and net namespace.
> > We've tested it, and it should not affect any other functionality.
> >
> > We will provide detailed information about the bug
> > in this email, along with a PoC to trigger it.
> >
> > ---- details below ----
> >
> > Bug details:
> >
> > inet_diag TCP dumps currently execute attacker-controlled
> > INET_DIAG_REQ_BYTECODE programs while still holding the listener,
> > bind, or ehash bucket locks in tcp_diag_dump(). If the bucket is
> > heavily populated and the bytecode is a large reject-all filter, the
> > dump path can spend an unbounded amount of time under the same bucket
> > lock while walking attacker-arranged sockets.
> >
> > The reproduced listener case places 131072 SO_REUSEPORT listeners onto
> > one colliding listener bucket
>
> This sounds very unlikely to happen.
>
> If you cannot trust your users, you should audit them
> properly (e.g. limit # of FDs, use BPF LSM, etc).
>
>
> [...]
> > ----BEGIN crash log----
> > [   18.495442] watchdog: BUG: soft lockup - CPU#0 stuck for 3s! [poc:10=
34]
> [...]
> > [   18.495449] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), B=
IOS unknown 2/2/2022
>
> It seems the soft lockup timeout was deliberately set to be short to
> trigger a splat, but 3s on QEMU should be much shorter on a real
> machine and it should not be a problem.

Hi,

Thanks for the feedback.

The 131072-listener setup is only a concentrated reproducer for the lock
scope issue. It is not meant to suggest that this exact population pattern
is common in normal deployments.

The issue we are trying to fix is that time spent under the bucket lock
can be amplified by bucket population together with inet_diag bytecode
cost, because the bytecode is currently evaluated while the bucket lock is
still held.

So the concern is not tied to one specific listener count or to the exact
watchdog threshold used in our local setup. The soft lockup report was
only used to make the long bucket-locked section visible in a small QEMU
environment.

The fix targets that locking property directly: keep the bucket-locked
section limited to socket collection and taking references, and move
bytecode/filter/fill work out of the critical section. This way, the batch
limit applies to raw bucket traversal itself, instead of allowing
additional work to accumulate while the lock is held.

Best regards,
Zihan