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

On 7/29/26 7:28 PM, Zihan Xi 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 and then issues a NETLINK_SOCK_DIAG dump
> request with 16380 INET_DIAG_BC_NOP instructions followed by a failing
> INET_DIAG_BC_D_EQ test. Because every socket runs the full bytecode and
> none reaches the reply fill path, skb backpressure does not terminate the
> walk early. On the unfixed kernel this triggers a watchdog soft lockup
> and then a panic in inet_diag_bc_sk().
>
> The earlier batching fix direction was still too narrow: it only counted
> sockets that survived the cheap prefilters and reached the expensive dump
> path. An attacker can therefore populate one bucket with many sockets or
> listeners that fail the netns/family/port or MPTCP-specific prefilters,
> causing the same bucket lock to be scanned far past the 16-entry batch
> threshold before control is returned.
>
> The same root cause also exists in MPTCP listener dumping. The
> MPTCP-specific mptcp_diag_dump_listeners() path reuses sk_diag_dump(),
> which runs inet_diag_bc_sk() before filling the netlink reply, while the
> listener bucket lock is still held.
>
> We additionally profiled the MPTCP-specific path locally with a
> separate debugging artifact. Because struct inet_diag_req_v2 stores
> sdiag_protocol in an __u8 field, that request must keep
> sdiag_protocol = IPPROTO_TCP and pass INET_DIAG_REQ_PROTOCOL =
> u32(IPPROTO_MPTCP), otherwise 262 truncates back to TCP and never reaches
> the MPTCP handler. With that corrected request, a 1-group run with 32768
> listeners and 16380 NOP bytecode steps took 2082.608 ms on the fixed
> kernel versus 8.601 ms on the unfixed kernel, and kprobe profiling showed
> inet_diag_bc_sk() executing 32768 times on the fixed kernel but only 256
> times on the unfixed one. That 256-count is not a missed path: the
> unfixed mptcp_diag_dump_listeners() reuses one counter both as the
> in-bucket index and as the resume cursor, so each dump restart advances
> in a triangular skip pattern and stops after approximately sqrt(2N)
> bytecode executions. The inline reproducer and decoded crash log below
> cover the TCP panic path; the MPTCP results above are included only as
> supporting local validation for the second patch.
>
> This series fixes both sites by keeping bucket-locked sections limited to
> raw socket collection and lifetime pinning, and moving all filtering,
> inet_diag_bc_sk(), and socket filling work out of the locked regions so
> the batch limit applies to raw bucket traversal itself. For TCP listener,
> bind, and ehash buckets, and for the MPTCP listener bucket, restarts now
> keep a referenced dump cursor so the next batch resumes after the
> previous socket instead of rescanning the bucket head under the same
> lock.
>
> For the TCP patch, the underlying root cause predates modern git history.
> The Fixes tag therefore uses commit 1da177e4c3f4
> ("Linux-2.6.12-rc2") as the earliest git-import boundary that still
> anchors the pre-git bug in the current repository, rather than
> incorrectly attributing it to a later helper or refactor commit. The
> MPTCP patch uses the real introduction boundary, commit 4fa39b701ce9
> ("mptcp: listen diag dump support").
>
> Reproducer:
>
>      gcc -O2 -static -o poc poc.c
>      unshare -Urn ./poc
>
> For the reproduced panic log below, we enabled
> softlockup panic sysctls and ran the local helper that executes:
>
>      ./poc --listen --groups 4 --stride 2048 --count 32768 --nops 16380
>
> We run the PoC in a 2 vCPU, 2 GB RAM x86 QEMU environment.
>
> ------BEGIN poc.c------
> #define _GNU_SOURCE
>
> #
[...]
> static size_t build_request(void *buf, bool listen_mode, bool with_attack,
> 			    unsigned int nops)
> {
> 	size_t msg_len = NLMSG_SPACE(sizeof(struct inet_diag_req_v2));
> 	struct nlmsghdr *nlh = buf;
> 	struct inet_diag_req_v2 *req;
>
> 	memset(buf, 0, msg_len);
> 	nlh->nlmsg_len = msg_len;
> 	nlh->nlmsg_type = SOCK_DIAG_BY_FAMILY;
> 	nlh->nlmsg_flags = NLM_F_REQUEST | NLM_F_DUMP;
> 	nlh->nlmsg_seq = 1;
>
> 	req = NLMSG_DATA(nlh);
> 	req->sdiag_family = AF_INET;
> 	req->sdiag_protocol = IPPROTO_TCP;
> 	req->idiag_states = listen_mode ? TCPF_LISTEN : (1U << 12);

1U << 12

12 is TCP_NEW_SYN_RECV. Is TCP_BOUND_INACTIVE what you expected ?


> 	req->id.idiag_cookie[0] = INET_DIAG_NOCOOKIE;
> 	req->id.idiag_cookie[1] = INET_DIAG_NOCOOKIE;