Procedures versus the "fastpath" API

The security team received a report from Theodor-Arsenij
Larionov-Trichkin of PostgresPro that it's possible to crash the
backend with an assertion or null-pointer dereference by trying to
call a window function via the "fast path function call" protocol
message.  fastpath.c doesn't set up any WindowObject function context,
of course, but most of the built-in window functions just assume there
will be one.  We concluded that there's no possibility of anything
more interesting than an immediate core dump, so per our usual rules
this isn't a CVE-grade bug.  However, we poked around to see if there
were any related problems, and soon found that fastpath.c will happily
attempt to call procedures as well as functions.  That seems to work,
accidentally IMO, for simple procedures --- but if the procedure tries
to COMMIT or ROLLBACK then you get "ERROR: invalid transaction
termination".  (There might be other edge-case problems; I've not
tried subtransactions or OUT parameters for example.)

So the question on the table is what to do about this.  As far as
window functions go, it seems clear that fastpath.c should just reject
any attempt to call a window function that way (or an aggregate for
that matter; aggregates fail already, but with relatively obscure
error messages).  Perhaps there's also an argument that window
functions should have run-time tests, not just assertions, that
they're called in a valid way.

As for procedures, I'm of the opinion that we should just reject those
too, but some other security team members were not happy with that
idea.  Conceivably we could attempt to make the case actually work,
but is it worth the trouble?  Given the lack of field complaints
about the "invalid transaction termination" failure, it seems unlikely
that it's occurred to anyone to try to call procedures this way.
We'd need special infrastructure to test the case, too, since psql
offers no access to fastpath calls.

A compromise suggestion was to prohibit calling procedures via
fastpath as of HEAD, but leave existing releases as they are,
in case anyone is using a case that happens to work.

Thoughts?

			regards, tom lane