From: Yeonggi Kim <yg.kim@navercorp.com>
Date: Tue, 22 Sep 2026 12:10:12 +0000 (+0900)
Subject: BUG/MEDIUM: server: skip log backend addr checks for internal proxies
X-Git-Tag: v3.5-dev8~104
X-Git-Url: https://git.kaiwu.me/?a=commitdiff_plain;h=4cf03304f6b242cd3580dbec491ff9745715d883;p=haproxy.git

BUG/MEDIUM: server: skip log backend addr checks for internal proxies

23e5f18b8 ("MEDIUM: sink: change the sink mode type to PR_MODE_SYSLOG")
tagged a sink's forward_px (the internal proxy backing a "ring" section)
with PR_MODE_SYSLOG "for compat checks" purposes, stating no behavior
change was expected. This unintentionally made ring's internal "server"
line subject to _srv_check_proxy_mode()'s log-backend compatibility
checks, which were only meant for real "mode log" backends.

Internal proxies (PR_CAP_INT) now fall through to the regular "else"
branch, i.e. the generic STREAM-transport check instead of the
family/DGRAM checks meant for log backends. Two independent
consequences follow from this, both regressions introduced by
23e5f18b8:

1. A "ring" section whose server targets a UNIX socket (a common
   pattern to feed a local "log-forward" section) is rejected at parse
   time with "log server address family not supported for log backend
   server", even though this worked fine before 23e5f18b8.

   Reproducer:

       global

       ring buf1
           server srv1 /tmp/repro-log-forward.sock

       log-forward relay
           bind unix@/tmp/repro-log-forward.sock mode 660
           log ring@buf1 local0

2. Less visibly, a ring server given a DGRAM address (e.g.
   "server s1 udp@127.0.0.1:1514") was, until now, let through the
   log-backend family check (DGRAM is not rejected there) and reaches
   connect_server() at runtime, which promptly segfaults in
   conn_select_mux_be() -> proto_is_quic() on a NULL proto, since a
   ring's forward_px only ever expects a STREAM transport. This patch
   also closes that crash, by routing rings back through the regular
   STREAM-only check that non-log backends already get.

40eb1dd13 ("BUG/MEDIUM: sink: fix unexpected double postinit of sink
backend") already gives the sink's forward_px the PR_CAP_INT capability
for a related reason (skip the automatic log-backend postinit, since
sink manages it manually). This reuses that same flag to also skip the
log-backend-specific address checks for the same class of proxies,
since they are never real user-configured log backends.

This should be backported up to 3.3, but only where 23e5f18b8 and
40eb1dd13 are backported too - without the latter (which sets
PR_CAP_INT on forward_px), this patch is a silent no-op.
---

diff --git a/src/server.c b/src/server.c
index 8cd97b978..b60be4ce3 100644
--- a/src/server.c
+++ b/src/server.c
@@ -3562,9 +3562,15 @@ static int _srv_check_proxy_mode(struct server *srv, char postparse)
 		goto out;
 	}
 
-	if (srv->proxy->mode == PR_MODE_SYSLOG) {
+	if (srv->proxy->mode == PR_MODE_SYSLOG && !(srv->proxy->cap & PR_CAP_INT)) {
 		/* log backend server (belongs to proxy with mode log enabled):
-		 * perform some compatibility checks
+		 * perform some compatibility checks. Internal proxies (PR_CAP_INT,
+		 * e.g. a sink's forward_px backing a "ring" section) are excluded:
+		 * they are tagged PR_MODE_SYSLOG for type-awareness purposes only
+		 * (see 23e5f18b8) and are not real user-configured log backends,
+		 * so they may legitimately target a UNIX socket (e.g. to feed a
+		 * local "log-forward" section). They still go through the regular
+		 * STREAM-transport check below, in the "else" branch.
 		 */
 
 		/* supported address family types are: