#914360 tinc: Random segfault after connection drop

Package:
tinc
Source:
tinc
Description:
Virtual Private Network daemon
Submitter:
Maximilian Stein
Date:
2018-11-23 17:21:11 UTC
Severity:
normal
#914360#5
Date:
2018-11-22 16:32:22 UTC
From:
To:
Dear Maintainer,

One instance of the tinc daemon crashed after running for quite a
while.

Syslog shows a peer's connection had dropped immediately before the
crash:

Nov 22 10:08:38 hostname tincd[691]: Flushing meta data to abcd (1.2.3.4 port 30458) failed: Connection reset by peer
Nov 22 10:08:38 hostname tincd[691]: Closing connection with abcd (1.2.3.4 port 30458)
Nov 22 10:08:38 hostname tincd[691]: Got ANS_KEY from efgh (5.6.7.8 port 50551) destination abcd which is not reachable
Nov 22 10:08:38 hostname tincd[691]: Connection from 1.2.3.4 port 22087
Nov 22 10:08:38 hostname kernel: [52018.886642] tincd[691]: segfault at 98c ip 0000557ae018e29d sp 00007ffffc40f5b0 error 4 in tincd[557ae0189000+19000]


This is the first and only time I have observed this behaviour. I hope
the provided information can help finding the issue.

Thanks!
Maximilian
#914360#10
Date:
2018-11-22 20:02:45 UTC
From:
To:
Hello Maximilian Stein,
maybe the package maintainer can get some information out of that
kernel line, but maybe you can install a core dump collector
like e.g. systemd-coredump.
When the next crash happens you can examine the core by:

coredumpctl list
coredumpctl gdb <PID>

Even better if debug symbols could be installed before. [1]


Now I see one thing - you are running 1.0.35-1, is this
a local rebuilt package or the package from testing?

If the latter with some guessing the location *could* be there:
   0x000000000000929d <send_meta+45>:   movslq 0x98c(%rbx),%rdx

And that would point to following line:
   src/meta.c:44              if(!c->outbuflen) {

But this is just based on the offsets and if the used package
was built by debian.


Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace
#914360#13
Date:
2018-11-22 20:02:45 UTC
From:
To:
Hello Maximilian Stein,
maybe the package maintainer can get some information out of that
kernel line, but maybe you can install a core dump collector
like e.g. systemd-coredump.
When the next crash happens you can examine the core by:

coredumpctl list
coredumpctl gdb <PID>

Even better if debug symbols could be installed before. [1]


Now I see one thing - you are running 1.0.35-1, is this
a local rebuilt package or the package from testing?

If the latter with some guessing the location *could* be there:
   0x000000000000929d <send_meta+45>:   movslq 0x98c(%rbx),%rdx

And that would point to following line:
   src/meta.c:44              if(!c->outbuflen) {

But this is just based on the offsets and if the used package
was built by debian.


Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace
#914360#18
Date:
2018-11-23 15:58:08 UTC
From:
To:
Dear Bernhard,

Thanks for your analysis!

In the meanwhile I have installed systemd-coredump, so I hope to be able
to provide more details in case tincd crashes again.

Indeed, I am running an unmodified version of the package from buster,
so your analysis should be correct. Maybe the connection object ptr c
was free'd or NULL?

Best,
Maximilian
#914360#23
Date:
2018-11-23 15:58:08 UTC
From:
To:
Dear Bernhard,

Thanks for your analysis!

In the meanwhile I have installed systemd-coredump, so I hope to be able
to provide more details in case tincd crashes again.

Indeed, I am running an unmodified version of the package from buster,
so your analysis should be correct. Maybe the connection object ptr c
was free'd or NULL?

Best,
Maximilian
#914360#26
Date:
2018-11-23 15:58:08 UTC
From:
To:
Dear Bernhard,

Thanks for your analysis!

In the meanwhile I have installed systemd-coredump, so I hope to be able
to provide more details in case tincd crashes again.

Indeed, I am running an unmodified version of the package from buster,
so your analysis should be correct. Maybe the connection object ptr c
was free'd or NULL?

Best,
Maximilian
#914360#31
Date:
2018-11-23 17:16:22 UTC
From:
To:
Hello Maximilian,

Am 23.11.2018 um 16:58 schrieb Maximilian Stein:

Yes, I think c was NULL at the time of the crash.

Kind regards,
Bernhard
#914360#34
Date:
2018-11-23 17:16:22 UTC
From:
To:
Hello Maximilian,

Am 23.11.2018 um 16:58 schrieb Maximilian Stein:

Yes, I think c was NULL at the time of the crash.

Kind regards,
Bernhard