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

On Wed, Jul 29, 2026 at 1:29=E2=80=AFPM Zihan Xi <[email protected]> wrote:
>
> 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:1034=
]
[...]
> [   18.495449] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIO=
S 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.