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

Archive Greenbone Community Edition
1

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]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7f2513718f20]
/lib/x86_64-linux-gnu/libc.so.6(+0x451b0)[0x7f251371f1b0]
/usr/lib/x86_64-linux-gnu/libopenvas_base.so.9(nvticache_get_category+0x41)[0x7f251439b471]
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?

2

Hi,

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:

3

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
4

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.

3 Likes