Check the fd number against FD_SETSIZE in PQsocketPoll

From: Roman Khapov <rkhapov(at)yandex-team(dot)ru>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Check the fd number against FD_SETSIZE in PQsocketPoll
Date: 2026-10-29 11:27:45
Message-ID: 985BA3B4-1281-451A-AE43-6ECCD87D75E4@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/5EF180BD-3951-4E8C-903D-D91EF54A338D@yandex-team.ru

--
Best regards,
Roman Khapov

Attachment Content-Type Size
0001-libpq-guard-select-fallback-against-fds-FD_SETSIZE.patch application/octet-stream 1.3 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Roman Khapov 2026-10-29 11:31:38 Re: kqueue backend for pgbench
Previous Message Jim Jones 2026-10-29 11:11:37 Uncancellable infinite loop in xpath() with entity references