Re: another cppcheck finding

[Илья Шипицин]

2017-10-04 9:15 GMT+05:00 Willy Tarreau :

> Hi Ilya,
>
> [also CCing Baptiste]
>
> On Tue, Oct 03, 2017 at 05:25:17PM +0500,  ??? wrote:
> > [src/dns.c:2502]: (error) Memory leak: buffer
> >
> >
> > I do not see any "buffer" usage except conditional free.
> > should we just remove "buffer" from there ?
>
> I think you're referring to this part :
>
> struct dns_resolution *dns_alloc_resolution(void)
> {
> struct dns_resolution *resolution = NULL;
> char *buffer = NULL;
>
> resolution = calloc(1, sizeof(*resolution));
> buffer = calloc(1, global.tune.bufsize);
>
> if (!resolution || !buffer) {
> free(buffer);
> free(resolution);
> return NULL;
> }
>
> LIST_INIT(>requester.wait);
> LIST_INIT(>requester.curr);
>
> return resolution;
> }
>
> And there's definitely a memory leak on the allocated buffer. Buffers
> used to be needed for resolution in the past but I think that's no
> longer the case, so I think that indeed the buffer can be completely
> removed (unless it should be assigned somewhere of course). It's
>

great. I'll send a patch today



> possible that there are other such places after the DNS processing
> was refactored some time ago.
>
> Thanks,
> Willy
>
> >
> > Cheers,
> > Ilya Shipitsin
>

Re: Haproxy segfault error 4 in libc-2.24

[Marcus Ulbrich]

Okay, mh if there is another way to forbid any kind of "sleep" as url 
parameter not crashing haproxy, I'll use this. Any ideas?


Where should I change this? I installed haproxy from repository...

Thanks for helping...
Marcus

Re: another cppcheck finding

[Willy Tarreau]

Hi Ilya,

[also CCing Baptiste]

On Tue, Oct 03, 2017 at 05:25:17PM +0500,  ??? wrote:
> [src/dns.c:2502]: (error) Memory leak: buffer
> 
> 
> I do not see any "buffer" usage except conditional free.
> should we just remove "buffer" from there ?

I think you're referring to this part :

struct dns_resolution *dns_alloc_resolution(void)
{
struct dns_resolution *resolution = NULL;
char *buffer = NULL;

resolution = calloc(1, sizeof(*resolution));
buffer = calloc(1, global.tune.bufsize);

if (!resolution || !buffer) {
free(buffer);
free(resolution);
return NULL;
}

LIST_INIT(>requester.wait);
LIST_INIT(>requester.curr);

return resolution;
}

And there's definitely a memory leak on the allocated buffer. Buffers
used to be needed for resolution in the past but I think that's no
longer the case, so I think that indeed the buffer can be completely
removed (unless it should be assigned somewhere of course). It's
possible that there are other such places after the DNS processing
was refactored some time ago.

Thanks,
Willy

> 
> Cheers,
> Ilya Shipitsin

Re: Haproxy segfault error 4 in libc-2.24

[Willy Tarreau]

On Wed, Oct 04, 2017 at 05:07:07AM +0200, Willy Tarreau wrote:
> On Wed, Oct 04, 2017 at 04:40:53AM +0200, Willy Tarreau wrote:
> > On Tue, Oct 03, 2017 at 06:57:45PM +0200, Marcus Ulbrich wrote:
> > > Hey Jarno,
> > > 
> > > This seems to work stable!
> > > The idea for this acl was to prevent attackers testing for example MySQL 
> > > injection by sleep command. ,,sleep" is in none of our URLs!
> > > Do you have an idea about an acl about this not crashing haproxy?
> > 
> > I wouldn't be surprized if there was an issue for example with a %00 causing
> > a length mismatch between two parts. At least now we have an idea where to
> > look for the bug. It shouldn't take very long anymore to spot the problem.
> 
> I'm seeing an issue in the url_dec sample converter :
> 
> static int sample_conv_url_dec(const struct arg *args, struct sample 
> *smp, void
> *private)
> {
> /* If the constant flag is set or if not size is avalaible at
>  * the end of the buffer, copy the string in other buffer
>   * before decoding.
>  */
> if (smp->flags & SMP_F_CONST || smp->data.u.str.size <= 
> smp->data.u.str.
> len) {
> struct chunk *str = get_trash_chunk();
> memcpy(str->str, smp->data.u.str.str, 
> smp->data.u.str.len);
> 
> Here it's missing a check to ensure that str.len <= str.size. Normally there
> is no known case where this could happen, but the preferred smp_dup() performs
> the check and truncates the input if needed. I don't know if there's a reason
> for this to ever happen. Hmmm in fact there's one theorical case where it 
> could
> happen, it's if the sample contains a full buffer (str.len == str.size), and
> then we can overflow the block by one byte when writing the trailing zero. But
> it's not possible in HTTP since the request is at least a few bytes long, and
> there's the reserve.
> 
> smp->data.u.str.str = str->str;
> smp->data.u.str.size = str->size;
> smp->flags &= ~SMP_F_CONST;
> }
> 
> So if you're interested, you can replace the block above by this :
> if (smp->flags & SMP_F_CONST || smp->data.u.str.size <= 
> smp->data.u.str.
> len)
> smp_dup(smp);
> 
> If this stops crashing we'll have to try to figure in which situation the
> case above may happen :-/

By the way if you manage to print the contents of "smp" in
sample_conv_str2lower() it could help, at least to find smp->str.{len,size}.

Willy

Re: Haproxy segfault error 4 in libc-2.24

[Willy Tarreau]

On Wed, Oct 04, 2017 at 04:40:53AM +0200, Willy Tarreau wrote:
> On Tue, Oct 03, 2017 at 06:57:45PM +0200, Marcus Ulbrich wrote:
> > Hey Jarno,
> > 
> > This seems to work stable!
> > The idea for this acl was to prevent attackers testing for example MySQL 
> > injection by sleep command. ,,sleep" is in none of our URLs!
> > Do you have an idea about an acl about this not crashing haproxy?
> 
> I wouldn't be surprized if there was an issue for example with a %00 causing
> a length mismatch between two parts. At least now we have an idea where to
> look for the bug. It shouldn't take very long anymore to spot the problem.

I'm seeing an issue in the url_dec sample converter :

static int sample_conv_url_dec(const struct arg *args, struct sample *smp, 
void
*private)
{
/* If the constant flag is set or if not size is avalaible at
 * the end of the buffer, copy the string in other buffer
  * before decoding.
 */
if (smp->flags & SMP_F_CONST || smp->data.u.str.size <= 
smp->data.u.str.
len) {
struct chunk *str = get_trash_chunk();
memcpy(str->str, smp->data.u.str.str, smp->data.u.str.len);

Here it's missing a check to ensure that str.len <= str.size. Normally there
is no known case where this could happen, but the preferred smp_dup() performs
the check and truncates the input if needed. I don't know if there's a reason
for this to ever happen. Hmmm in fact there's one theorical case where it could
happen, it's if the sample contains a full buffer (str.len == str.size), and
then we can overflow the block by one byte when writing the trailing zero. But
it's not possible in HTTP since the request is at least a few bytes long, and
there's the reserve.

smp->data.u.str.str = str->str;
smp->data.u.str.size = str->size;
smp->flags &= ~SMP_F_CONST;
}

So if you're interested, you can replace the block above by this :
if (smp->flags & SMP_F_CONST || smp->data.u.str.size <= 
smp->data.u.str.
len)
smp_dup(smp);

If this stops crashing we'll have to try to figure in which situation the
case above may happen :-/

Willy

Re: Haproxy segfault error 4 in libc-2.24

[Willy Tarreau]

On Tue, Oct 03, 2017 at 06:57:45PM +0200, Marcus Ulbrich wrote:
> Hey Jarno,
> 
> This seems to work stable!
> The idea for this acl was to prevent attackers testing for example MySQL 
> injection by sleep command. ,,sleep" is in none of our URLs!
> Do you have an idea about an acl about this not crashing haproxy?

I wouldn't be surprized if there was an issue for example with a %00 causing
a length mismatch between two parts. At least now we have an idea where to
look for the bug. It shouldn't take very long anymore to spot the problem.

Willy

Re: [PATCH] BUG/MAJOR: tcp/http: set-dst-port action broken

[Willy Tarreau]

Hi Baptiste,

On Tue, Oct 03, 2017 at 11:31:37PM +0200, Baptiste wrote:
> Hi,
> 
> A regression has been introduced into the function handling TCP/HTTP action
> "set-dst-port".
> It actually does not change the right port (changing the source port on the
> server side connection instead of changing the destination one).
> 
> The patch in attachment fixes this issue.

Now applied (and stepped down to medium), thanks!

Willy

[PATCH] BUG/MAJOR: tcp/http: set-dst-port action broken

[Baptiste]

Hi,

A regression has been introduced into the function handling TCP/HTTP action
"set-dst-port".
It actually does not change the right port (changing the source port on the
server side connection instead of changing the destination one).

The patch in attachment fixes this issue.

Baptiste
From 8cf82be9a8d424804386f3818536716731bd8f74 Mon Sep 17 00:00:00 2001
From: Baptiste Assmann 
Date: Tue, 3 Oct 2017 23:16:36 +0200
Subject: [PATCH] BUG/MAJOR: tcp/http: set-dst-port action broken

A regression has been introduced in commit
5ce5a14310d248c9f20af9ef258d245d43b1: the port being changed is the
one from 'cli_conn->addr.from' instead of 'cli_conn->addr.to'.

This patch fixes the regression.

Backport status: should be backported to HAProxy 1.7 and above.
---
 src/proto_tcp.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/proto_tcp.c b/src/proto_tcp.c
index 0fad867..fdb897e 100644
--- a/src/proto_tcp.c
+++ b/src/proto_tcp.c
@@ -1300,14 +1300,14 @@ enum act_return tcp_action_req_set_dst_port(struct act_rule *rule, struct proxy
 
 		smp = sample_fetch_as_type(px, sess, s, SMP_OPT_DIR_REQ|SMP_OPT_FINAL, rule->arg.expr, SMP_T_SINT);
 		if (smp) {
-			if (cli_conn->addr.from.ss_family == AF_INET6) {
-((struct sockaddr_in6 *)_conn->addr.from)->sin6_port = htons(smp->data.u.sint);
+			if (cli_conn->addr.to.ss_family == AF_INET6) {
+((struct sockaddr_in6 *)_conn->addr.to)->sin6_port = htons(smp->data.u.sint);
 			} else {
-if (cli_conn->addr.from.ss_family != AF_INET) {
-	cli_conn->addr.from.ss_family = AF_INET;
-	((struct sockaddr_in *)_conn->addr.from)->sin_addr.s_addr = 0;
+if (cli_conn->addr.to.ss_family != AF_INET) {
+	cli_conn->addr.to.ss_family = AF_INET;
+	((struct sockaddr_in *)_conn->addr.to)->sin_addr.s_addr = 0;
 }
-((struct sockaddr_in *)_conn->addr.from)->sin_port = htons(smp->data.u.sint);
+((struct sockaddr_in *)_conn->addr.to)->sin_port = htons(smp->data.u.sint);
 			}
 		}
 	}
-- 
2.7.4

Re: Haproxy segfault error 4 in libc-2.24

[Marcus Ulbrich]

Hey Jarno,

This seems to work stable!
The idea for this acl was to prevent attackers testing for example MySQL 
injection by sleep command. „sleep“ is in none of our URLs!
Do you have an idea about an acl about this not crashing haproxy?

Thanks a lot!
Marcus 

Re: Haproxy segfault error 4 in libc-2.24

[Jarno Huuskonen]

Hi,

On Tue, Oct 03, Marcus Ulbrich wrote:
>     #denysleep arguments in url
>     acl sleeper url_sub,url_dec,lower -m sub sleep(
>     http-request deny if sleeper

Stack trace had sample_conv_str2lower:
>> #4 sample_conv_str2lower (arg_p=, smp=0x7fff217f4f80, 
>> private=) at src/sample.c:1518

So try w/out the sleeper acl ?

-Jarno

-- 
Jarno Huuskonen

Re: Haproxy segfault error 4 in libc-2.24

[Vincent Bernat]

 ❦  3 octobre 2017 17:54 +0200, Marcus Ulbrich  :

> yes... it crashed after 5mins also without this acl.

I was suspecting this ACL as this is the only one with a
case-insensitive match. But maybe the same codepath is used when
matching header names.

> I should test commenting all acl for testing. Is there no way to see
> what acl was active, when haproxy crashes?

While in gdb, you are likely to be able to do, but I can't say exactly
how. Just with the information you provided, I think other people are
more likely to pinpoint the ACL triggering the code path you get and the
cause.

Of course, you can also comment all ACL one by one until crash
disappear. This would also help.
-- 
Avoid multiple exits from loops.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Haproxy segfault error 4 in libc-2.24

[Marcus Ulbrich]

yes... it crashed after 5mins also without this acl.

I should test commenting all acl for testing. Is there no way to see 
what acl was active, when haproxy crashes?


Thank you very much so far...

Re: Haproxy segfault error 4 in libc-2.24

[Vincent Bernat]

 ❦  3 octobre 2017 16:34 +0200, Marcus Ulbrich  :

>     acl badbots hdr_reg(User-Agent) -i -f /etc/haproxy/badbots.lst
>     http-request deny if badbots !whitelistips_agents

Try removing this one and check if it still crashes (hoping there is
only one crash).
-- 
By trying we can easily learn to endure adversity.  Another man's, I mean.
-- Mark Twain

Re: Haproxy segfault error 4 in libc-2.24

[Marcus Ulbrich]

Okay...
here is the config:
There is another frontend for port 8080... but the same scheme... I left 
it out here...


global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    maxconn 4000
    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private
    # Default ciphers to use on SSL-enabled listening sockets.
    # For more information, see ciphers(1SSL).
    ssl-default-bind-ciphers 
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS

    ssl-default-bind-options no-sslv3 no-tlsv10
    tune.ssl.default-dh-param 4096
defaults
    log global
    mode http
    option httplog
    option dontlognull
    option forwardfor
    option http-server-close
    option redispatch
    option abortonclose
    timeout http-request 60s
    timeout connect 60s
    timeout client 60s
    timeout server 300s
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http
listen stats
    bind/:2000/
/    mode http/
/    stats enable/
/    stats hide-version/
/    stats realm Haproxy\ Statistics/
/    stats uri //
/    stats auth xxx:xxx/
/    stats admin if TRUE/
/frontend http_XXX_frontend/
/    bind X.X.X.X:80/
/    bind X.X.X.X:443 ssl crt /etc/haproxy/cert/xxx.pem/
/    mode http/
/    option httpclose/
/    option forwardfor/
/    option http-server-close/
/    ### Logging/
/    capture request header Host len 40/
/    capture request header X-Forwarded-For len 50/
/    capture request header Accept-Language len 50/
/    capture request header Referer len 200/
/    capture request header User-Agent len 200/
/    capture response header Content-Type len 30/
/    capture response header Content-Encoding len 10/
/    capture response header Cache-Control len 200/
/    capture response header Last-Modified len 200/
/    ###/
/    ### SSL/
/    acl secure dst_port eq 443/
/    rsprep ^Set-Cookie:\ (./) Set-Cookie:\ \1;\ Secure if secure
    ###
    ### acl filter and protection of ddos attacks
    #Slowlorisprotection
    timeout http-request 5s
    # whitelist bots | blacklist attackers & accept others wiht 
time/concurrence restrictions

    tcp-request connection accept if { src -f /etc/haproxy/whitelist.lst }
    tcp-request connection reject if { src -f /etc/haproxy/blacklist.lst }
    # Dont allow more than 30 concurrent tcp connections OR 10 
connections in 1s

    tcp-request connection reject if { src_conn_rate(Abuse) ge 30 }
    tcp-request connection reject if { src_conn_cur(Abuse) ge 30 }
    tcp-request connection track-sc1 src table Abuse
    tcp-request content reject if { src_get_gpc0(Abuse) gt 0 }
    # blacklist bad bots and crawler with eg wget,curl… but allow all 
agents to whitelist

    tcp-request inspect-delay 3s
    acl whitelistips_agents src -f /etc/haproxy/whitelistips_agents.lst
    acl badbots hdr_reg(User-Agent) -i -f /etc/haproxy/badbots.lst
    http-request deny if badbots !whitelistips_agents
    #denysleep arguments in url
    acl sleeper url_sub,url_dec,lower -m sub sleep(
    http-request deny if sleeper
    # Dont allow more than 10 requests in 1 second
    acl abuse src_http_req_rate(Abuse) ge 100
    acl flag_abuser src_inc_gpc0(Abuse) ge 0
    acl scanner src_http_err_rate(Abuse) ge 10
    # Returns a 403 to the abuser and flags for tcp-reject next time
    http-request deny if abuse flag_abuser
    http-request deny if scanner flag_abuser
    ###
    ### lets encrypt
    acl lets_encrypt path_beg /.well-known/acme-challenge/
    use_backend lets_encrypt if lets_encrypt
    ###
    default_backend http_xxx_backend
backend http_xxx_backend
    mode http
    ### SSL
    http-request set-header X-Forwarded-Port %[dst_port]
    http-request add-header X-Forwarded-Proto https if { ssl_fc }
    ###
    balance roundrobin
    cookie SERVERID insert indirect nocache
    option httpchk HEAD /
    server x1 X.X.X.X:80 cookie x1 weight 2 check inter 1 port 80 
maxconn 32 on-marked-down shutdown-sessions
    server x2 X.X.X.X:80 cookie x2 weight 1 check inter 1 port 80 
maxconn 16 on-marked-down shutdown-sessions
    server x3 X.X.X.X:80 cookie x3 weight 3 check inter 1 port 80 
maxconn 64 on-marked-down shutdown-sessions
    server x4 X.X.X.X:80 cookie x4 weight 4 check inter 1 port 80 
maxconn 128 on-marked-down shutdown-sessions
    server x0 X.X.X.X:80 cookie x0 backup check inter 1 port 80 
maxconn 64 on-marked-down shutdown-sessions

backend Abuse
    stick-table type ip size 1m expire 30s store 
conn_rate(3s),conn_cur,gpc0,http_req_rate(10s),http_err_rate(20s)

Re: Consider mentioning haproxystats in the site

[Willy Tarreau]

On Tue, Oct 03, 2017 at 02:39:30PM +0200, Pavlos Parissis wrote:
> >> Forgot to mention that link for the project:
> >> https://github.com/unixsurfer/haproxystats
> > 
> > Sure! Where do you want it to appear exactly ?
> > 
> > Willy
> > 
> 
> Under the quick links section in the main page, below the link for 'Herald: 
> load feedback agent'.

Sounds goode, now done.

Cheers,
Willy

Re: Consider mentioning haproxystats in the site

[Pavlos Parissis]

On 03/10/2017 01:55 μμ, Willy Tarreau wrote:
> Hi Pavlos,
> 
> On Wed, Sep 27, 2017 at 11:40:07AM +0200, Pavlos Parissis wrote:
>> On 27/09/2017 10:36 ?u, Pavlos Parissis wrote:
>>> Hello all,
>>>
>>> haproxystats has been running for more than one year in production and has 
>>> been proven stable and
>>> very useful.
>>>
>>
>> Forgot to mention that link for the project:
>> https://github.com/unixsurfer/haproxystats
> 
> Sure! Where do you want it to appear exactly ?
> 
> Willy
> 

Under the quick links section in the main page, below the link for 'Herald: 
load feedback agent'.

Thanks,
Pavlos





signature.asc
Description: OpenPGP digital signature

another cppcheck finding

[Илья Шипицин]

hello!



[src/dns.c:2502]: (error) Memory leak: buffer


I do not see any "buffer" usage except conditional free.
should we just remove "buffer" from there ?

Cheers,
Ilya Shipitsin

Re: Consider mentioning haproxystats in the site

[Willy Tarreau]

Hi Pavlos,

On Wed, Sep 27, 2017 at 11:40:07AM +0200, Pavlos Parissis wrote:
> On 27/09/2017 10:36 ?u, Pavlos Parissis wrote:
> > Hello all,
> > 
> > haproxystats has been running for more than one year in production and has 
> > been proven stable and
> > very useful.
> > 
> 
> Forgot to mention that link for the project:
> https://github.com/unixsurfer/haproxystats

Sure! Where do you want it to appear exactly ?

Willy

Re: resolve memory leak in contrib/halog/halog.c

[Willy Tarreau]

Hi,

On Tue, Oct 03, 2017 at 10:14:44AM +0500,  ??? wrote:
> Ack/Nack ?

sorry, I didn't notice it. Now applied, thanks!

Willy

Re: Haproxy segfault error 4 in libc-2.24

[Willy Tarreau]

On Mon, Oct 02, 2017 at 05:16:13PM +0200, Vincent Bernat wrote:
>  ?  2 octobre 2017 17:06 +0200, Marcus Ulbrich  
> :
> 
> > I even get no core dump with the python oneliner either with chroot
> > nor without...
> 
> So, kernel.core_pattern seems to be problematic (unrelated, but my
> python one-liner wasn't totally correct either). Try again with just
> "core", the core file should be in the current directory. If it works,
> retry with HAProxy and you should get the core in /var/lib/haproxy.

The other stuff often preventing the cores from being dumped is the
presence of a "user" or "uid" directive in the global section. Either
you have to remove it or you need to set /proc/sys/fs/suid_dumpable to 1.

Willy

Re: Haproxy segfault error 4 in libc-2.24

[Vincent Bernat]

 ❦  3 octobre 2017 11:29 +0200, Marcus Ulbrich  :

> and here is the coredump with libssl and haproxy... I can not get
> clear about this:

Not the same one as previously. But this one is entirely in HAProxy. For
this one, I think an excerpt of your configuration would help. It seems
that one HTTP ACL is not working as expected.
-- 
Kindness is a language which the deaf can hear and the blind can read.
-- Mark Twain

Re: Aw: Re: Haproxy segfault error 4 in libc-2.24

[Vincent Bernat]

 ❦  3 octobre 2017 11:15 +0200, lu...@gmx.net :

>> Could you get another one with libssl1.1-dbgsym installed?
>
> Mmmh there is no libssl1.1-dbgsym in stretch, only in sid?
>
> I do think we need those stack traces from libssl.

It should be there. But you need to enable the right repository:

https://wiki.debian.org/AutomaticDebugPackages
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [PATCHES][ssl] Add 0-RTT support with OpenSSL 1.1.1

[Emmanuel Hocdet]

Hi Olivier,

Great to see a version of more ‘secure’ 0-RTT implementation.

> Le 2 oct. 2017 à 17:18, Olivier Houchard  a écrit :
> 
> Hi,
> 
> The attached patches add experimental support for 0-RTT with OpenSSL 1.1.1
> They are based on Emmanuel's previous patches, so I'm submitting them again,
> updated to reflect the changes in OpenSSL API, and with a few fixes.
> To allow the use of early data, one has to explicitely add "allow-0rtt" to
> its bind line. If early data are provided by the client, a
> "Early-Data: 1" header will be added, to let the origin server know that.
> 
> Because early data have security implications, a new sample fetch was added,
> "ssl_fc_has_early", a boolean that will be evaluated to true if early data
> were provided, as well as new action, "wait-for-handshake", which will make
> haproxy wait for the completion of the SSL handshake before processing the
> request. After the handshake, early data are considered as normal data, and
> they won't be reported to the origin server.
> 
> As usual, bugs are to be expected, and any review and/or test will be
> appreciated.
> 

I have tested the experimental version of 0-RTT few months ago with BoringSSL
and the option it’s a great candidate to per-certificat parameter. I attach the 
patch
to show howto set it (without BC_SSL_O_* flag).

I hope to be able to review your work in more detail.

++
Manu



early_data.diff
Description: Binary data

Re: Haproxy segfault error 4 in libc-2.24

[Marcus Ulbrich]

Hey,
thank you all for helping!

okay the output you wish to know:

Package: libssl1.1
Source: openssl
Version: 1.1.0f-3
Installed-Size: 3524
Maintainer: Debian OpenSSL Team 
Architecture: amd64
Depends: libc6 (>= 2.14), debconf (>= 0.5) | debconf-2.0
Breaks: salt-common (<= 2016.3.3+ds-3)
Description-de: Werkzeugsatz für das Secure Socket Layer (SSL) - 
Laufzeitbibliotheken
 Dieses Paket ist Teil der vom Projekt OpenSSL entwickelten 
Implementierung der

 Kryptographieprotokolle SSL und TLS für sichere Internetkommunikation.
 Dieses Paket enthält die Laufzeitbibliotheken libssl und libcrypto.
Description-md5: 88547c6206c7fbc4fcc7d09ce100d210
Multi-Arch: same
Homepage: https://www.openssl.org/
Tag: role::shared-lib
Section: libs
Priority: important
Filename: pool/main/o/openssl/libssl1.1_1.1.0f-3_amd64.deb
Size: 1342180
MD5sum: 7f2182fae1edb494e3c00d60a397fa20
SHA256: f77a765439d2ae76d74f417afcf6dd806cab98ff950e6ee59a5f6c10e521d7f7


and here is the coredump with libssl and haproxy... I can not get clear 
about this:


Program received signal SIGSEGV, Segmentation fault.

__memmove_sse2_unaligned_erms () at 
../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:512


512 
../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S: 
Datei oder Verzeichnis nicht gefunden.



(gdb) bt

#0 __memmove_sse2_unaligned_erms () at 
../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:512


#1 0x55af86b99d23 in memcpy (__len=, __src=out>, __dest=) at 
/usr/include/x86_64-linux-gnu/bits/string3.h:53


#2 smp_dup (smp=smp@entry=0x7fff217f4f80) at src/sample.c:669

#3 0x55af86b99de0 in smp_make_rw (smp=0x7fff217f4f80) at 
include/proto/sample.h:163


#4 sample_conv_str2lower (arg_p=, smp=0x7fff217f4f80, 
private=) at src/sample.c:1518


#5 0x55af86b9a674 in sample_process (px=px@entry=0x55af87ae4fd0, 
sess=sess@entry=0x55af87e3ca60, strm=strm@entry=0x55af87e37c60, 
opt=opt@entry=6, expr=0x55af87c92760, p=p@entry=0x7fff217f4f80)


at src/sample.c:1079

#6 0x55af86b970f4 in acl_exec_cond (cond=0x55af87c90080, 
px=px@entry=0x55af87ae4fd0, sess=sess@entry=0x55af87e3ca60, 
strm=strm@entry=0x55af87e37c60, opt=6, opt@entry=2) at src/acl.c:1147


#7 0x55af86b5f817 in http_req_get_intercept_rule 
(px=px@entry=0x55af87ae4fd0, rules=rules@entry=0x55af87ae5018, 
s=s@entry=0x55af87e37c60, deny_status=deny_status@entry=0x7fff217f5114)


at src/proto_http.c:3457

#8 0x55af86b64c77 in http_process_req_common 
(s=s@entry=0x55af87e37c60, req=req@entry=0x55af87e37c70, 
an_bit=an_bit@entry=16, px=0x55af87ae4fd0) at src/proto_http.c:4301


#9 0x55af86b91fb8 in process_stream (t=0x55af87e3caf0) at 
src/stream.c:1794


#10 0x55af86b1fe35 in process_runnable_tasks () at src/task.c:238

#11 0x55af86b13646 in run_poll_loop () at src/haproxy.c:1733

#12 0x55af86b0f8a9 in main (argc=, argv=out>) at src/haproxy.c:2114


(gdb) bt full [1/7461]

#0 __memmove_sse2_unaligned_erms () at 
../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:512


No locals.

#1 0x55af86b99d23 in memcpy (__len=, __src=out>, __dest=) at 
/usr/include/x86_64-linux-gnu/bits/string3.h:53


No locals.

#2 smp_dup (smp=smp@entry=0x7fff217f4f80) at src/sample.c:669

trash = 0x55af86e22140 

#3 0x55af86b99de0 in smp_make_rw (smp=0x7fff217f4f80) at 
include/proto/sample.h:163


smp = 0x7fff217f4f80

#4 sample_conv_str2lower (arg_p=, smp=0x7fff217f4f80, 
private=) at src/sample.c:1518


No locals.

#5 0x55af86b9a674 in sample_process (px=px@entry=0x55af87ae4fd0, 
sess=sess@entry=0x55af87e3ca60, strm=strm@entry=0x55af87e37c60, 
opt=opt@entry=6, expr=0x55af87c92760, p=p@entry=0x7fff217f4f80)


at src/sample.c:1079

conv_expr = 0x55af87c913c0

#6 0x55af86b970f4 in acl_exec_cond (cond=0x55af87c90080, 
px=px@entry=0x55af87ae4fd0, sess=sess@entry=0x55af87e3ca60, 
strm=strm@entry=0x55af87e37c60, opt=6, opt@entry=2) at src/acl.c:1147


suite = 0x55af87c87960

term = 0x55af87c8de10

expr = 0x55af87c996d0

acl = 0x55af87c96670

smp = {flags = 8, data = {type = 6, u = {sint = 94212383796048, ipv4 = 
{s_addr = 2276158288}, ipv6 = {__in6_u = {__u6_addr8 = 
"Pk\253\207\257U\000\000\000@\000\000\377\377\377\377", __u6_addr16 = {


27472, 34731, 21935, 0, 16384, 0, 65535, 65535}, __u6_addr32 = 
{2276158288, 21935, 16384, 4294967295}}}, str = {str = 0x55af87ab6b50 
"Set-Cookie: SERVERID=x2; path=/", size = 16384,


len = -1}, meth = {meth = 80, str = {str = 0x4000 Cannot access memory at address 0x4000>, size = 0, len = 
0, ctx = {p = 0x0, i = 0, ll = 0, d = 0, a = {0x0,


0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, px = 0x55af87ae4fd0, sess = 
0x55af87e3ca60, strm = 0x55af87e37c60, opt = 6}


acl_res = ACL_TEST_FAIL

suite_res = ACL_TEST_PASS

cond_res = ACL_TEST_FAIL

#7 0x55af86b5f817 in http_req_get_intercept_rule 
(px=px@entry=0x55af87ae4fd0, rules=rules@entry=0x55af87ae5018, 
s=s@entry=0x55af87e37c60, 

Aw: Re: Haproxy segfault error 4 in libc-2.24

[lukyt]

Hello,



> Could you get another one with libssl1.1-dbgsym installed?

Mmmh there is no libssl1.1-dbgsym in stretch, only in sid?

I do think we need those stack traces from libssl.



> Okay... I've got a core dump... Thanks a lot!!!
>
> But what this means?

Is the openssl package uptodate? It should be 1.1.0f-3.

Please provide the output of:
apt-cache show libssl1.1


cheers,
lukas