Hi hackers! While digging into the pgbench client fd handling discussed in [0] (the FD_SETSIZE cap on select(2)-based platforms), I also looked at the client-side library itself and noticed that libpq has the same latent problem.
PQsocketPoll() uses poll(2) when available, but its fallback path calls select(2) with FD_SET(sock, ...) on a socket descriptor without any check. If the application happens to hold a thousand or so open files before connecting, socket(2) can return an fd >= FD_SETSIZE, and FD_SET() then silently writes beyond the fd_set - i.e. stack corruption. Patch attached: fail cleanly with EINVAL instead of corrupting the stack. This only affects platforms without poll(2) (essentially Windows and ancient Unixes?), and the branch is not even compiled on modern systems... but I think defending here is cheap and worthwhile. [0] - https://www.postgresql.org/message-id/[email protected] -- Best regards, Roman Khapov
0001-libpq-guard-select-fallback-against-fds-FD_SETSIZE.patch
Description: Binary data
