should we need to pre-validate the sendmsg size and validate it using fixed value math.MaxUint32

[Chaunceyctx]

NOTE: if you are reporting is a potential security vulnerability or a crash,
please follow our CVE process at
https://github.com/grpc/proposal/blob/master/P4-grpc-cve-process.md instead of
filing an issue here.

Please see the FAQ in our main README.md, then answer the questions below
before submitting your issue.

What version of gRPC are you using?

grpc v1.59.0

What version of Go are you using (go version)?

go1.22.0

What operating system (Linux, Windows, …) and version?

linux amd64

What did you do?

If possible, provide a recipe for reproducing the error.

I used grpc.MaxSendMsgSize(math.MaxUint64) to create grpcServer. But

grpc-go/rpc_util.go

Line 695 in 5565631

if uint(b.Len()) > math.MaxUint32 {

this method validates the send msg size with fixed MaxUint32. This is less than math.MaxUint64. So may be we need to remove this code chunk and validate the send msg size after compressing and involving header data in

grpc-go/server.go

Line 1140 in 5565631

func (s *Server) sendResponse(ctx context.Context, stream *transport.ServerStream, msg any, cp Compressor, opts *transport.WriteOptions, comp encoding.Compressor) error {

What did you expect to see?

math.MaxUint64 value will work

What did you see instead?

get error grpc: message too large

[arjan-bal]

Hi @Chaunceyctx, the the gRPC over HTTP/2 protocol requires a 4 byte header in every message.

The repeated sequence of Length-Prefixed-Message items is delivered in DATA frames
Length-Prefixed-Message → Compressed-Flag Message-Length Message
Compressed-Flag → 0 / 1 ; encoded as 1 byte unsigned integer
Message-Length → {length of Message} ; encoded as 4 byte unsigned integer (big endian)
Message → *{binary octet}

gRPC Go only supports HTTP/2 transports presently. This puts an upper limit of 4GB (2^32 bytes) on the message size. This is the reason for the math.MaxUint32 check in the encode function.

There is a lower limit of 2GB when using the protbuf codec.

We could move theuint(b.Len()) > math.MaxUint32 check after the compression is performed and while complying with the gRPC protocol. This would give a little more headroom for large messages, however since you're relying on compression to bring the size below the threshold, you may see significant failures when compression ratio is low. We don't want to make this behaviour change without a strong motivation to do so.

[github-actions]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[Chaunceyctx]

@arjan-bal got it! thanks :)