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

On Fri, Jul 31, 2026 at 3:58 AM Kuniyuki Iwashima [off-list ref] wrote:

On Wed, Jul 29, 2026 at 1:29 PM Zihan Xi [off-list ref] wrote:

quoted

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


[...]

quoted

----BEGIN crash log----
[   18.495442] watchdog: BUG: soft lockup - CPU#0 stuck for 3s! [poc:1034]

[...]

quoted

[   18.495449] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 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