Openvas log reaches the disk usage up to 100%

[oikonomou]

Hello,

We are running the latest openvas version found in apt in Linux Kali distribution (see OS details below).

The openvas.log (see below) is filled with a lot of the same warnings _(sd main:WARNING:xxxx-xx-xx xxhxx.xx utc:xxxxx: pluginlaunch_wait_for_free_process: Invalid argument)_. This happens when having one or more targets.

The scan ends up getting stuck as the whole disk reaches up to100% of usage due to the mentioned log. After that the machine needs a reboot to empty that log. The scans never complete.

We came across to this issue while running OpenVAS in Ubuntu 20.4 after building openvas from source. We were using OpenVAS 20.8 before without that issue, but it appeared after upgrading it to 21.x version.

We tried different 21.x versions including the earliest one (21.4.0) but it seems to have this issue since then.

We noticed that this warning is generated very early on the scan progress and one of the running process is always one as follows :

openvas: testing xx.xxx.xxx.xx (/var/lib/openvas/plugins/nmap.nasl)

We reproduce it on Kali OS after installing openvas without building from the source ourselves. We followed the steps from here. The issue is still the same.

We wrote a post in the forum about this issue, but we couldn't find any answers. https://community.greenbone.net/t/strange-scan-behaviour-wait-for-free-process-warning/11148/4

GVM versions

gsa: 21.4.3

gvm:21.4.4

openvas:21.4.3

gvm-libs:21.4.3

ospd-openvas:21.4.3

Environment

Operating system: Linux kali 5.14.0

└─$ lsb_release -a
No LSB modules are available.
Distributor ID: Kali
Description:    Kali GNU/Linux Rolling
Release:    2021.4
Codename:   kali-rolling

Installation method / source: (packages, source installation) apt-get install openvas

Logfiles

openvas.log

sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument
sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument
sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument
sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument
sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument
sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument
sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument
sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument
sd   main:WARNING:2022-01-11 16h17.27 utc:59144: pluginlaunch_wait_for_free_process: Invalid argument

Let me know if anything more is needed. Hope I could find some help!

Thank you!

[Kraemii]

Hello, I took a first look into it and it seems weird, that this happens on different machines and installing methods, as I never ran into this issue. Can you give me more information about the scan target? Did you always use the same target for scanning? Also what about the feed. Did you updated it after updating openvas?

[nichtsfrei]

I guess that it could be related to either

      sigemptyset (&mask);
      sigaddset (&mask, SIGCHLD);
      if (sigtimedwait (&mask, NULL, &ts) < 0 && errno != EAGAIN)
        g_warning ("%s: %s", __func__, strerror (errno));

at least EINVAL seems to indicate that.

I will try to reproduce this issue by lowering max_checks and run a couple of scripts on a Ubuntu machine.

[nichtsfrei]

I tried with Ubuntu 21.10 and wasn't able to reproduce this issue based on source compiled openvas and low max_checks alone do you have more information about your runtime environment?

Are you using a VM, docker?

Do you run into the same issue when you're building openvas from source?

[oikonomou]

We ran more tests on this and identified the issue with these warnings.

For every scan we run, we're using a custom scan config and in it, we set

scanner_plugins_timeout: -1

Without that value for this variable, the openvas.log is clear from these warnings, so we guess this is the culprit for all this logging.

a) One consideration, maybe, for the 21.x openvas is that these warnings were far less(sometimes none) in 20.x versions. Any thoughts on that finding?

b) We basically want to set that scanner_plugins_timeout to infinite so that openvas won't cancel any port scanning process (completing nmap.nasl. plugin may take days some times). Is there any value suitable for disabling the timeout in your opinion?

Thanks all for the help and the testing!

[cfi-gb]

While it is not explicitly documented:

1. No plugin is allowed to be running infinitely
2. Both plugins_timeout and scanner_plugins_timeout settings requires a positive value for their value (seconds)
3. Passing -1 isn't supported / is invalid and thus the Invalid argument logging / error is seen

[oikonomou]

Thank you @cfi-gb for your comment!

Is there a maximum accepted integer value in settings like scanner_plugins_timeout and plugins_timeout?

[ArnoStiefvater]

The maximum accepted value is INT_MAX.