SEGFAULT in cfg_parse_peers() #2872

WhiteWLf-dev · 2025-02-19T21:19:24Z

Detailed Description of the Problem

When I give mycfg.cfg file to haproxy with -f args, I got SEGFAULT.
[New Thread 0x7ffff71ff6c0 (LWP 3688482)]
[Thread 0x7ffff71ff6c0 (LWP 3688482) exited]
[NOTICE] (3688479) : haproxy version is 3.2-dev5
[NOTICE] (3688479) : path to executable is /home/as/projects/upstream/newhaproxy/haproxy/haproxy
[ALERT] (3688479) : config : parsing [tt:1]: unknown keyword '00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' out of section.
[ALERT] (3688479) : config : parsing [tt:3] : 'peers' cannot handle unexpected argument '0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'.

Thread 1 "haproxy" received signal SIGSEGV, Segmentation fault.
0x000055555570450a in cfg_parse_peers (file=0x555555be0d10 "tt", linenum=4, args=0x7fffffffd850, kwm=) at src/cfgparse.c:850
850 if (cfg_peers->local && !cfg_peers->local->id && local_peer) {
(gdb) bt
#0 0x000055555570450a in cfg_parse_peers (file=0x555555be0d10 "tt", linenum=4, args=0x7fffffffd850, kwm=) at src/cfgparse.c:850
#1 0x0000555555706a77 in parse_cfg (cfg=cfg@entry=0x555555bdef00) at src/cfgparse.c:2621
#2 0x0000555555764e52 in read_cfg () at src/haproxy.c:1010
#3 0x00005555555c7f8b in main (argc=, argv=) at src/haproxy.c:3215

Expected Behavior

Error message without SEGFAULT.

Steps to Reproduce the Behavior

Run haproxy as:
./haproxy -f mycfg.txt

mycfg1.txt

Do you have any idea what may have caused this?

No response

Do you have an idea how to solve the issue?

if (!cfg_peers) {
err_code |= ERR_ALERT | ERR_ABORT;
goto out;
}
if (cfg_peers->local && !cfg_peers->local->id && local_peer) {

What is your configuration?

debian-12
x86-64 intel
8192 mb RAM
CC="gcc" make -e TARGET=linux-glibc USE_SYSTEMD=1 V=1 DESTDIR=debian/haproxy PREFIX=/usr IGNOREGIT=true MANDIR=/usr/share/man DOCDIR=/usr/share/doc/haproxy USE_PCRE2=1 USE_PCRE2_JIT=1 USE_OPENSSL=1 USE_SLZ=1 USE_LUA=1 USE_PROMEX=1 USE_OT=1 LUA_INC=/usr/include/lua5.3
EXTRA=admin/halog/halog ADDLIB="-latomic"

Output of `haproxy -vv`

HAProxy version 3.2-dev5 2025/02/08 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Running on: Linux 6.1.90-1-generic #astra2+ci15 SMP PREEMPT_DYNAMIC Tue Jul 23 09:49:19 MSK 2024 x86_64
Build options : 
  TARGET  = linux-glibc
  CC      = gcc
  CFLAGS  = -O2 -g -fwrapv
  OPTIONS = USE_OPENSSL=1 USE_LUA=1 USE_SLZ=1 USE_OT=1 USE_PROMEX=1 USE_PCRE2=1 USE_PCRE2_JIT=1
  DEBUG   = 

Feature list : -51DEGREES +ACCEPT4 +BACKTRACE -CLOSEFROM +CPU_AFFINITY +CRYPT_H -DEVICEATLAS +DL -ENGINE +EPOLL -EVPORTS +GETADDRINFO -KQUEUE -LIBATOMIC +LIBCRYPT +LINUX_CAP +LINUX_SPLICE +LINUX_TPROXY +LUA +MATH -MEMORY_PROFILING +NETFILTER +NS -OBSOLETE_LINKER +OPENSSL -OPENSSL_AWSLC -OPENSSL_WOLFSSL +OT -PCRE +PCRE2 +PCRE2_JIT -PCRE_JIT +POLL +PRCTL -PROCCTL +PROMEX -PTHREAD_EMULATION -QUIC -QUIC_OPENSSL_COMPAT +RT +SLZ +SSL -STATIC_PCRE -STATIC_PCRE2 +TFO +THREAD +THREAD_DUMP +TPROXY -WURFL -ZLIB

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_TGROUPS=16, MAX_THREADS=256, default=12).
Built with SSL library version : OpenSSL 3.2.1-dev 
Running on SSL library version : OpenSSL 3.2.1-dev 
SSL library supports TLS extensions : yes
SSL library supports SNI : yes
SSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
OpenSSL providers loaded : default gostprov
Built with Lua version : Lua 5.3.6
Built with the Prometheus exporter as a service
Built with network namespace support.
Built with OpenTracing support.
Built with libslz for stateless compression.
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built with PCRE2 version : 10.42 2022-12-11
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with gcc compiler version 12.2.0

Available polling systems :
      epoll : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
         h2 : mode=HTTP  side=FE|BE  mux=H2    flags=HTX|HOL_RISK|NO_UPG
  <default> : mode=HTTP  side=FE|BE  mux=H1    flags=HTX
         h1 : mode=HTTP  side=FE|BE  mux=H1    flags=HTX|NO_UPG
       fcgi : mode=HTTP  side=BE     mux=FCGI  flags=HTX|HOL_RISK|NO_UPG
  <default> : mode=SPOP  side=BE     mux=SPOP  flags=HOL_RISK|NO_UPG
       spop : mode=SPOP  side=BE     mux=SPOP  flags=HOL_RISK|NO_UPG
  <default> : mode=TCP   side=FE|BE  mux=PASS  flags=
       none : mode=TCP   side=FE|BE  mux=PASS  flags=NO_UPG

Available services : prometheus-exporter
Available filters :
        [BWLIM] bwlim-in
        [BWLIM] bwlim-out
        [CACHE] cache
        [COMP] compression
        [FCGI] fcgi-app
        [  OT] opentracing
        [SPOE] spoe
        [TRACE] trace

Last Outputs and Backtraces

(gdb) bt full
#0  0x000055555570450a in cfg_parse_peers (file=0x555555be0d10 "tt", linenum=4, args=0x7fffffffd850, kwm=<optimized out>) at src/cfgparse.c:850
        local_peer = 0
        peer = 0
        parse_addr = 0
        curpeers = 0x0
        bind_addr = 0x0
        nb_shards = 0
        newpeer = 0x0
        err = <optimized out>
        bind_conf = <optimized out>
        err_code = 0
        errmsg = 0x0
        bind_line = 0
        peer_line = 0
        __func__ = <optimized out>
#1  0x0000555555706a77 in parse_cfg (cfg=cfg@entry=0x555555bdef00) at src/cfgparse.c:2621
        status = <optimized out>
        kwm = <optimized out>
        end = <optimized out>
        line = <optimized out>
        arg = 2
        args = {0x555555cfcf40 "server", 0x555555cfcf47 '0' <repeats 200 times>..., 0x555555cfd8c0 "" <repeats 63 times>}
        thisline = 0x555555cfbf30 "    server ", '0' <repeats 189 times>...
        linesize = 4096
        linenum = 4
        err_code = <optimized out>
        cs = 0x555555bdfcf0
        pcs = <optimized out>
        ics = <optimized out>
        readbytes = 0
        outline = 0x555555cfcf40 "server"
        outlen = 2433
        outlinesize = 3072
        fatal = <optimized out>
        missing_lf = -1
        nested_cond_lvl = 0
        nested_conds = {4150455968, 32767, 4150658080, 32767, 1435036779, 21845, 4294957696, 32767, 1434710649, 21845, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, 1434946467, 21845, 4160606442, 32767, 
          NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, 6177, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, 4152302784, 32767, 1435036138, 21845, NESTED_COND_ELSE_DROP, NESTED_COND_IF_TAKE, 
          1439669984, 21845, 4160606442, 32767, 1435757120, 21845, 4152302688, 32767, 33, NESTED_COND_IF_TAKE, 8064, 65535, 4278190335, 16711680, 4294957008, 32767, 1439668546, 21845, 3753684224, 3743218222, 
          1439668544, 21845, 1439668544, 21845, 4294957248, 32767, 1434710649, 21845, 4294957416, 32767, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, 4294957008, 32767, 4150908760, 32767, 1668623914, 1819225446, 
          NESTED_COND_IF_SKIP, NESTED_COND_IF_TAKE, 4222451713, 1936286765, 1439668544, 21845, 1439668544, 21845, 1439668544, 21845, 1439668544, 21845, 1439668546, 21845, 1439668546, 21845, 1439668544, 21845, 
          1439668546, 21845, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, 
          NESTED_COND_IF_TAKE, NESTED_COND_IF_TAKE, 808464432, 128, 808464432, 808464432}
--Type <RET> for more, q to quit, c to continue without paging--c
        errmsg = 0x0
        cur_position = 0x555555cf7c78 ""
        file = 0x555555be0d10 "tt"
        next_line = <optimized out>
#2  0x0000555555764e52 in read_cfg () at src/haproxy.c:1010
        ret = <optimized out>
        env_cfgfiles = 0x555555cf9940 "tt"
        cfg = 0x555555bdef00
        err_code = 0
#3  0x00005555555c7f8b in main (argc=<optimized out>, argv=<optimized out>) at src/haproxy.c:3215
        devnullfd = -1
        limit = {rlim_cur = 1048576, rlim_max = 1048576}
        intovf = <optimized out>
        cfg = <optimized out>
        cfg_tmp = <optimized out>
        tmp_startup_logs = 0x0
        proc = <optimized out>
        msg = 0x55555587888b "READY\n"
        msg = <optimized out>

Additional Information

No response

The text was updated successfully, but these errors were encountered:

einval22 · 2025-02-20T09:53:42Z

Hi WhiteWLf-dev ,

Thanks for your report !

In order to gather more info: do you use some custom build for this test ?

I'm asking this, because you've reported the version 3.2-dev5.

Normally, with this version, stack trace should be ( from main() -> to cfg_parse_peers())

main()
read_cfg_in_discovery_mode() ---> here we read and validate only the global section to discover runtime mode, other sections are skipped;
read_cfg() --> scan and parse other sections
cfg_parse_peers()

Thanks in advance,

einval22 · 2025-02-20T10:07:53Z

I've reproduced on my side with "unmodified" official dev release.

Indeed this segfaults with your config example. Thanks for the report !

einval22 · 2025-02-20T11:41:38Z

This patch below should fix this crash:

diff --git a/src/cfgparse.c b/src/cfgparse.c
index 216c8dcfe..60a569045 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -794,8 +794,10 @@ int cfg_parse_peers(const char *file, int linenum, char **args, int kwm)
                        goto out;
                }

-               if (alertif_too_many_args(1, file, linenum, args, &err_code))
+               if (alertif_too_many_args(1, file, linenum, args, &err_code)) {
+                       err_code |= ERR_ABORT;
                        goto out;
+               }

                err = invalid_char(args[1]);
                if (err) {

I think the best solution here is to stop the parser immediately with ERR_ABORT, instead of accumulating ERR_FATAL and try to parse "peer" keywords within the wrongly declared "peers" section, because we may have more than one "peers" section and by this we may risk to associate a peer "haproxy4" with a wrong section "mypeers".
The latter will give a mess in configured stick tables...

...
peers mypeers
     peer haproxy1 192.168.0.1:1024
     peer haproxy2 192.168.0.2:1024
     peer haproxy3 10.2.0.1:1024

peers yet_another  __some_garbage___
     peer haproxy4 10.0.3.68:10000

In addition, if we will just signal "peers yet_another some_garbage_" by an alert at start and won't parse its contents, haproxy can start anyway with such buggy conf (number of fatal errors < 50).
Sooner or later a user will notice on production, that there is a problem with the peer "haproxy4" and he will need to search and to check startup logs to find the root cause.

WhiteWLf-dev · 2025-02-20T11:47:54Z

So did you try delete one symbol on first line? The problem will be disappeared and I can't understand why. Definitely, it depends on size of some buffers (for trash and etc) and I can't detect type of the buffer and where it's placed. @einval22

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue haproxy#2872. This should be backported in all stable versions.

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue #2872. This should be backported in all stable versions.

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue haproxy#2872. This should be backported in all stable versions. (cherry picked from commit 390df28) Signed-off-by: Willy Tarreau <w@1wt.eu> (cherry picked from commit f595db1) Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue haproxy#2872. This should be backported in all stable versions. (cherry picked from commit 390df28) Signed-off-by: Willy Tarreau <w@1wt.eu> (cherry picked from commit f595db1) Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com> (cherry picked from commit a864292) Signed-off-by: Willy Tarreau <w@1wt.eu>

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue haproxy#2872. This should be backported in all stable versions. (cherry picked from commit 390df28) Signed-off-by: Willy Tarreau <w@1wt.eu>

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue haproxy#2872. This should be backported in all stable versions. (cherry picked from commit 390df28) Signed-off-by: Willy Tarreau <w@1wt.eu> (cherry picked from commit f595db1) Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com> (cherry picked from commit a864292) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com>

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue #2872. This should be backported in all stable versions. (cherry picked from commit 390df28) Signed-off-by: Willy Tarreau <w@1wt.eu> (cherry picked from commit f595db1) Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com> (cherry picked from commit a864292) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com> (cherry picked from commit 4ebda48) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com>

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue haproxy#2872. This should be backported in all stable versions. (cherry picked from commit 390df28) Signed-off-by: Willy Tarreau <w@1wt.eu> (cherry picked from commit f595db1) Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com> (cherry picked from commit a864292) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com> (cherry picked from commit 4ebda48) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com> (cherry picked from commit 62651b9) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com>

When "peers" keyword is followed by more than one argument and it's the first "peers" section in the config, cfg_parse_peers() detects it and exits with "ERR_ALERT|ERR_FATAL" err_code. So, upper layer parser, parse_cfg(), continues and parses the next keyword "peer" and then he tries to check the global cfg_peers, which should contain "my_cluster". The global cfg_peers is still NULL, because after alerting a user in alertif_too_many_args, cfg_parse_peers() exited. peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In order to fix this, let's add ERR_ABORT, if "peers" keyword is followed by more than one argument. Like this parse_cfg() will stops immediately and terminates haproxy with "too many args for peers my_cluster..." alert message. It's more reliable, than add checks "if (cfg_peers !=NULL)" in "peer" subparser, as we may have many "peers" sections. peers my_another_cluster peer haproxy1 1.1.1.2 1000 peers my_cluster __some_wrong_data__ peer haproxy1 1.1.1.1 1000 In addition, for the example above, parse_cfg() will parse all configuration until the end and only then terminates haproxy with the alert "too many args...". Peer haproxy1 will be wrongly associated with my_another_cluster. This fixes the issue haproxy#2872. This should be backported in all stable versions. (cherry picked from commit 390df28) Signed-off-by: Willy Tarreau <w@1wt.eu> (cherry picked from commit f595db1) Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com> (cherry picked from commit a864292) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com> (cherry picked from commit 4ebda48) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com> (cherry picked from commit 62651b9) Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com> (cherry picked from commit c16b5bf) Signed-off-by: Willy Tarreau <w@1wt.eu>

WhiteWLf-dev added status: needs-triage This issue needs to be triaged. type: bug This issue describes a bug. labels Feb 19, 2025

einval22 added the status: reviewed This issue was reviewed. A fix is required. label Feb 20, 2025

einval22 mentioned this issue Feb 20, 2025

SEGFAULT in init_peers_frontend() #2870

Closed

einval22 removed the status: needs-triage This issue needs to be triaged. label Feb 20, 2025

wlallemand removed 1.6 This issue affects the HAProxy 1.6 stable branch. 1.7 This issue affects the HAProxy 1.7 stable branch. labels Feb 20, 2025

wtarreau removed 3.0 This issue affects the HAProxy 3.0 stable branch. 3.1 This issue affects the HAProxy 3.1 stable branch. labels Mar 20, 2025

capflam removed the 2.9 This issue affects the HAProxy 2.9 stable branch. label Apr 15, 2025

capflam removed status: reviewed This issue was reviewed. A fix is required. 2.6 This issue affects the HAProxy 2.6 stable branch. 2.8 This issue affects the HAProxy 2.8 stable branch. labels Apr 22, 2025

capflam closed this as completed Apr 22, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SEGFAULT in cfg_parse_peers() #2872

SEGFAULT in cfg_parse_peers() #2872

SEGFAULT in cfg_parse_peers() #2872

SEGFAULT in cfg_parse_peers() #2872

Comments

Detailed Description of the Problem

Expected Behavior

Steps to Reproduce the Behavior

Do you have any idea what may have caused this?

Do you have an idea how to solve the issue?

What is your configuration?

Output of haproxy -vv

Last Outputs and Backtraces

Additional Information

Output of `haproxy -vv`