On 11/11/22 07:13, Peter Eisentraut wrote: > On 09.11.22 00:08, Jacob Champion wrote: >> pqGetNegotiateProtocolVersion3() is still ignoring the message length, >> though; it won't necessarily stop at the message boundary. > > I don't follow. The calls to pqGetInt(), pqGets(), etc. check the > message length.
I may be missing something obvious, but I don't see any message length checks in those functions, just bounds checks on the connection buffer. > Do you have something else in mind? Can you give an > example or existing code? Sure. Consider the case where the server sends a NegotiateProtocolVersion with a reasonable length, but then runs over its own message (either by sending an unterminated string as one of the extension names, or by sending a huge extension number). When I test that against a client on my machine, it churns CPU and memory waiting for the end of a message that will never come, even though it had already decided that the maximum length of the message should have been less than 2K. Put another way, why do we loop around and poll for more data when we hit the end of the connection buffer, if we've already checked at this point that we should have the entire message buffered locally? >+ initPQExpBuffer(&buf); >+ if (pqGetInt(&tmp, 4, conn) != 0) >+ return EOF; Tangentially related -- I think the temporary PQExpBuffer is being leaked in the EOF case. --Jacob
