| 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 |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Jim Jones | 2026-10-29 11:11:37 | Uncancellable infinite loop in xpath() with entity references |