upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-06-09 00:32:33 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 10

BUG/MINOR: sockpair: set FD_CLOEXEC on fd received via SCM_RIGHTS
Some checks are pending
Contrib / build (push) Waiting to run
Details
alpine/musl / gcc (push) Waiting to run
Details
VTest / Generate Build Matrix (push) Waiting to run
Details
VTest / (push) Blocked by required conditions
Details
Windows / Windows, gcc, all features (push) Waiting to run
Details

Browse source 
FDs received through recv_fd_uxst() do not have FD_CLOEXEC set.
The equivalent sock_accept_conn() already handles this correctly:
any FD accepted or received in the master must be marked close-on-exec
to avoid leaking it across the execvp() performed on soft-reload.

This is currently triggering a leak in the master since 3.1: the worker
sends a socketpair fd to the master  to issue the _send_status CLI
command, and recv_fd_uxst() receive it without setting FD_CLOEXEC.  If a
re-exec is emitted before the master had the chance to close that fd, it
survives execvp() and appears as an untracked unnamed AF_UNIX socket in
the new master generation.

This must be backported to all maintained branches.
This commit is contained in:
William Lallemand 2026-03-16 16:08:45 +01:00
parent a3bf0de651
commit ab7acdcc3a
1 changed files with 4 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
src/proto_sockpair.c
View file

@ -488,8 +488,11 @@ struct connection *sockpair_accept_conn(struct listener *l, int *status)
int ret;
int cfd;
if ((cfd = recv_fd_uxst(l->rx.fd)) != -1)
if ((cfd = recv_fd_uxst(l->rx.fd)) != -1) {
fd_set_nonblock(cfd);
if (master)
fd_set_cloexec(cfd);
}
if (likely(cfd != -1)) {
/* Perfect, the connection was accepted */