Re: [PATCH] SUNRPC: Validate TCP record marker length before trusting it

[Chu Zhou <jack.wemmick@gmail.com>]

Ping - three weeks on with no review or ack.

Re-verified this morning: it still applies cleanly to current mainline
(v7.3-rc7), diffstat unchanged at 2 files, 44 insertions.

  https://lore.kernel.org/linux-nfs/6ab4b4fd.8f0cbdd2.2427cb.7612@mx.google.com/

I went back over the error path end to end, since the whole mechanism
rests on it. xs_read_stream()'s out_err label is

	return ret != 0 ? ret : -ESHUTDOWN;

and at the point the new check fires, ret still holds the positive
byte count returned by xs_read_stream_header(), so the patch assigns
-ESHUTDOWN explicitly before branching there. That value then reaches
xs_stream_data_receive(), which calls
kernel_sock_shutdown(transport->sock, SHUT_RDWR), and the existing
transport reset machinery re-establishes the connection as described in
the commit message.

Worth restating that the failure mode is a hard hang, not a throughput
problem. The parser latched onto a bogus reclen after below-RPC
corruption, then discarded every genuine reply through the MSG_TRUNC
path while the TCP connection stayed ESTABLISHED - nothing ever
triggered a reset, and the hung task watchdog panicked the machine.
Restarting the server was the only recovery.

Two-line check plus a tracepoint, one comparison per fragment. The 16 MiB
bound is a judgement call - happy to lower it or tie it to a named
constant if that is preferred.

Thanks,