NVT Cache (table in DB) not getting generated with openvas9 | 7.0.3-2bionic

Clean install of openvas9 | 7.0.3-2bionic (on Ubuntu 18.04.1 LTS).

Upon finishing, NVT cache won’t generate, even after scanner has been started and openvasmd --rebuild has been run (NOTE: did have to perform kb_location = /var/run/redis/redis.sock fix to be able to start the scanner).

Here’s the output of openvas-check-setup:

Step 1: Checking OpenVAS Scanner …
OK: OpenVAS Scanner is present in version 5.1.3.
OK: redis-server is present in version v=4.0.9.
OK: scanner (kb_location setting) is configured properly using the redis-server socket: /var/run/redis/redis.sock
OK: redis-server is running and listening on socket: /var/run/redis/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: NVT collection in /var/lib/openvas/plugins contains 47718 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
SUGGEST: Enable signature checking (see http://www.openvas.org/trusted-nvts.html).
WARNING: The initial NVT cache has not yet been generated.
SUGGEST: Start OpenVAS Scanner for the first time to generate the cache.
Step 2: Checking OpenVAS Manager …
OK: OpenVAS Manager is present in version 7.0.3.
OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
OK: OpenVAS Manager database is at revision 184.
OK: OpenVAS Manager expects database at revision 184.
OK: Database schema is up to date.
ERROR: The number of NVTs in the OpenVAS Manager database is too low.
FIX: Make sure OpenVAS Scanner is running with an up-to-date NVT collection and run ‘openvasmd --rebuild’.

… and yes, I have both run greenbone-nvt-sync and restarted the scanner. Multiple times. NVTs still don’t get added to /var/lib/openvas/mgr/tasks.db.

Checking openvassd.messages it looks like openvassd is having a segmentation fault while doing a call to /usr/lib/x86_64-linux-gnu/libopenvas_base.so.9 in Ubuntu 18:

SIGSEGV occured !
openvassd: Serving /var/run/openvassd.sock(sighand_segv+0x7c)[0x40d8ec]
openvassd: Serving /var/run/openvassd.sock(send_plug_info+0x1d)[0x40819d]
openvassd: Serving /var/run/openvassd.sock(comm_send_pluginlist+0x32)[0x408432]
openvassd: Serving /var/run/openvassd.sock(comm_send_nvt_info+0x117)[0x4087e7]
openvassd: Serving /var/run/openvassd.sock(ntp_parse_input+0x180)[0x409de0]
openvassd: Serving /var/run/openvassd.sock(comm_wait_order+0x4e)[0x40862e]
openvassd: Serving /var/run/openvassd.sock[0x40a3ff]

SIGSEGV does NOT happen with openvas9 | 7.0.3-1 running on Ubuntu 16, it is specific to openvas9 | 7.0.3-2bionic on Ubuntu 18.

Any ideas on what is causing this SIGSEGV and how to fix this?


it seems that this could be caused by some corrupt data in your redis database. It might help to flush your Redis-DB (see e.g. the redis-cli command line tool).

There are now two PRs open which should warn you about such situations and without segfaulting:

As a general note please always report segmentation faults (SIGSEGV) to the bugtracker of the related module throwing that segfault. For the openvassd the fitting one would be:

1 Like

Wow, you were absolutely right – a redis-cli -s /var/run/redis/redis.sock FLUSHALL fixed the problem! Thanks!

I’ll properly report the segmentation fault for tracking purposes.