Welcome! Log In Create A New Profile

Advanced

Haproxy 1.8 segfaults on misconfigured set server fqdn command

Posted by Lukas Tribus 
Hello,


the "set server <backend>/<server> fqdn <FQDN>" admin socket command
requires the internal DNS resolver to be configured and enabled for
that specific server. This is undocumented, and I will provide a doc
fix soon.


However, when the resolver is not configured, and when haproxy is
compiled with thread support, after issuing the set server fqdn admin
socket command, haproxy segfaults (from haproxy 1.8.0 to current 1.9
head):

#0 0x0000000000462b54 in srv_set_fqdn (srv=0x107feb0,
hostname=0x10bc4ea "google.ch", dns_locked=0) at src/server.c:3904
3904 HA_SPIN_LOCK(DNS_LOCK, &srv->resolvers->lock);
(gdb) bt
#0 0x0000000000462b54 in srv_set_fqdn (srv=0x107feb0,
hostname=0x10bc4ea "google.ch", dns_locked=0) at src/server.c:3904
#1 0x000000000046329b in update_server_fqdn (server=0x107feb0,
fqdn=0x10bc4ea "google.ch", updater=0x562a94 "stats socket command",
dns_locked=0) at src/server.c:4093
#2 0x0000000000463dfb in cli_parse_set_server (args=0x7fff6b730df0,
payload=0x0, appctx=0x10bc270, private=0x0) at src/server.c:4322
#3 0x00000000004e1a58 in cli_parse_request (appctx=0x10bc270) at src/cli..c:468
#4 0x00000000004e2028 in cli_io_handler (appctx=0x10bc270) at src/cli.c:649
#5 0x000000000052fc8b in task_run_applet (t=0x10bc410,
context=0x10bc270, state=16385) at src/applet.c:49
#6 0x000000000052cf59 in process_runnable_tasks () at src/task.c:384
#7 0x00000000004b87fc in run_poll_loop () at src/haproxy.c:2386
#8 0x00000000004b8b60 in run_thread_poll_loop (data=0x10b9190) at
src/haproxy.c:2451
#9 0x00000000004ba2f6 in main (argc=4, argv=0x7fff6b731578) at
src/haproxy.c:3053
(gdb) bt full
#0 0x0000000000462b54 in srv_set_fqdn (srv=0x107feb0,
hostname=0x10bc4ea "google.ch", dns_locked=0) at src/server.c:3904
__pl_l = 0x90
__pl_r = 17548531
resolution = 0x10bc4ea
hostname_dn = 0x107feb0 "\003\002\002"
hostname_len = 4205728
hostname_dn_len = 0
#1 0x000000000046329b in update_server_fqdn (server=0x107feb0,
fqdn=0x10bc4ea "google.ch", updater=0x562a94 "stats socket command",
dns_locked=0) at src/server.c:4093
msg = 0x7f33421092f0
#2 0x0000000000463dfb in cli_parse_set_server (args=0x7fff6b730df0,
payload=0x0, appctx=0x10bc270, private=0x0) at src/server.c:4322
sv = 0x107feb0
warning = 0x7ac020 <cli_kws> "\260\303z"
#3 0x00000000004e1a58 in cli_parse_request (appctx=0x10bc270) at src/cli..c:468
args = {0x10bc4d0 "set", 0x10bc4d4 "server", 0x10bc4db "test",
0x10bc4e5 "fqdn", 0x10bc4ea "google.ch", 0x10bc4f4 "port", 0x10bc4f9
"81", 0x10bc4fb "" <repeats 58 times>}
p = 0x10bc4fb ""
end = 0x10bc4fb ""
payload = 0x0
i = 65
kw = 0x7ac260 <cli_kws+576>
#4 0x00000000004e2028 in cli_io_handler (appctx=0x10bc270) at src/cli.c:649
str = 0x10bc4d0 "set"
si = 0x10bc0e0
req = 0x10bbe40
res = 0x10bbea0
bind_conf = 0x1078b40
reql = 44
len = 43
#5 0x000000000052fc8b in task_run_applet (t=0x10bc410,
context=0x10bc270, state=16385) at src/applet.c:49
app = 0x10bc270
si = 0x10bc0e0
#6 0x000000000052cf59 in process_runnable_tasks () at src/task.c:384
t = 0x10bc410
state = 16385
ctx = 0x10bc270
process = 0x52fbdc <task_run_applet>
t = 0x10bc410
max_processed = 199
#7 0x00000000004b87fc in run_poll_loop () at src/haproxy.c:2386
next = 934842768
exp = 934842311
#8 0x00000000004b8b60 in run_thread_poll_loop (data=0x10b9190) at
src/haproxy.c:2451
ptif = 0x7b7d70 <per_thread_init_list>
ptdf = 0x7fff6b731490
start_lock = 0
#9 0x00000000004ba2f6 in main (argc=4, argv=0x7fff6b731578) at
src/haproxy.c:3053
tids = 0x10b9190
threads = 0x10b91b0
i = 1
old_sig = {__val = {2048, 8031360, 140734996092320, 5080516,
140734996092320, 140734996091728, 5749721, 140734996091968,
554050781193, 128, 140734996091760, 140734996091952, 140733193388035,
32, 140734996091792, 140734996091759}}
blocked_sig = {__val = {18446744067199990583,
18446744073709551615 <repeats 15 times>}}
err = 0
retry = 200
limit = {rlim_cur = 2031, rlim_max = 2031}
errmsg = "\000\273\006\001\000\000\000\000 k\251A3\177\000\000
\000\000\000\000\000\000\000\300\003\002\000\000\000\000\[email protected]\274\006\001\000\000\000\000x\025sk\377\177\000\000\004\000\000\000\000\000\000\000\312muA3\177\000\000\060\024sk\377\177\000\000+\000\000\000\000\000\000\[email protected]\024sk\377\177\000\000\200\214z\000\000\000\000\000\240\025sk"
pidfd = -1
(gdb) quit




The repro is as simple as not using a resolver, while haproxy is
compiled with thread support (linux2628 target) and issuing the set
server fqdn command:

command: echo "set server test/www1 fqdn google.com" | socat stdio /tmp/sock1

config:
global
maxconn 1000
stats socket /tmp/sock1 mode 666 level admin
stats timeout 1d
defaults
mode http
timeout connect 4s
timeout client 29s
timeout server 5s

resolvers googledns
nameserver 8888 8.8.8.8:53
nameserver 8844 8.8.4.4:53
hold valid 600s

frontend myfrontend
bind :80
default_backend test

backend test
server www1 neverssl.com:80 #resolvers googledns resolve-prefer ipv4




cheers,
lukas
Frederic Lecaille
Re: Haproxy 1.8 segfaults on misconfigured set server fqdn command
August 28, 2018 04:30PM
On 08/14/2018 11:27 AM, Lukas Tribus wrote:
> Hello,

Hi,

> the "set server <backend>/<server> fqdn <FQDN>" admin socket command
> requires the internal DNS resolver to be configured and enabled for
> that specific server. This is undocumented, and I will provide a doc
> fix soon.
>
>
> However, when the resolver is not configured, and when haproxy is
> compiled with thread support, after issuing the set server fqdn admin
> socket command, haproxy segfaults (from haproxy 1.8.0 to current 1.9
> head):

As this bug came with b418c122 I take a look at it. It has been fixed
then came back with thread support.

Reg testing file provided.

Fred.
Hi guys,

On Tue, Aug 28, 2018 at 04:26:19PM +0200, Frederic Lecaille wrote:
> As this bug came with b418c122 I take a look at it. It has been fixed then
> came back with thread support.

I just found this patch by pure luck, so I applied it since it looks
perfectly valid. Fred in the future, please be sure to send patches to
be applied out of a thread (or easier, CC me), as I'm not reading all
e-mails of all threads, and I'd even say that whenever I see that a
thread is properly handled by skilled people I don't read it at all :-)

Thanks,
Willy
Sorry, only registered users may post in this forum.

Click here to login