OpenVAS scanner 5.1.3 SIGSEGV after about an hour

[uwedisch]

Expected behavior

Scan is finishing successfully.

Current behavior

Scan stops with Sig SEGV.

Steps to reproduce

1. Start scan against the target. Currently I scan against a customers /24-network and 4 IP addresses show this behaviour. I scanned against each IP address with a separate scan.
2. Each scan is running for about an hour and then crashing. HTTP server logfile shows that this was after request numbered 108000 (or the like).
3. Each scan stops with Sig SEGV for these 4 IP addresses out of the whole network. The other IP addresses of this network are scanable.

The special thing of these 4 IP addresses are:

• Each of them is loadbalanced to 2 or 3 local IP addresses (only port 80 and 443).
• For each of them all uploaded attachments are scanned from an anti malware solution.
• Other ports than 80 and 443 are blocked at router level.

GVM versions

gsa: (gsad --version)
7.0.3
gvm: (gvmd --version)

openvas-scanner: (openvassd --version)
5.1.3
gvm-libs:

openvas-smb:

Environment

Operating system:
Kali Linux Rolling
Installation method / source: (packages, source installation)
From Kali Linux Rolling

Logfiles

[Mon Jun 24 13:22:56 2019][24632] Starts a new scan. Target(s) : x.x.x.x, with max_hosts = 1 and max_checks = 1
[Mon Jun 24 13:22:56 2019][24632] hosts_ordering: Random.
[Mon Jun 24 13:22:56 2019][24632] exclude_hosts: Skipped 0 host(s).
[Mon Jun 24 13:22:56 2019][24656] Testing x.x.x.x (x.x.x.x) [24656]
[Mon Jun 24 14:19:06 2019][19884] Received the Terminated signal
[Mon Jun 24 14:19:06 2019][24656] Process 27643 (OID: 1.3.6.1.4.1.25623.1.0.107307) seems to have died too early
SIGSEGV occured !
openvassd: testing x.x.x.x(sighand_segv+0x60)[0x4897c0]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7f9ad7c]
/lib/i386-linux-gnu/libc.so.6(+0x33c20)[0xb7a96c20]
/lib/i386-linux-gnu/libc.so.6(strtol+0x29)[0xb7a96aa9]
/usr/lib/i386-linux-gnu/libopenvas_base.so.9(nvticache_get_timeout+0x34)[0xb7ee66c4]
openvassd: testing x.x.x.x(plugin_launch+0x2bf)[0x4871bf]
openvassd: testing x.x.x.x(+0x60d2)[0x4820d2]
openvassd: testing x.x.x.x(+0x67b8)[0x4827b8]
openvassd: testing x.x.x.x(create_process+0xa7)[0x489557]
openvassd: testing x.x.x.x(attack_network+0x87d)[0x48327d]

[jjnicola]

Looking in the backtrace, it seems that the problem was with the conversion from a string to long int, inside the nvticache_get_timeout(). Probably because a miss configuration in the custom plugin timeout.
This function was already removed with greenbone/gvm-libs#581
So, the problem shouldn't be present anymore in our current branches.
Closing here.