Running host_details.nasl earns all memory

Building from Source and Advanced Topics
1

I have updated GVM to GVM-25.04.0 (based on Kali Linux). And postges was updated from 17 to 18
After update I got memory leak at the end of the configured scans. I’ve tested on one host with configured Maximum concurrently executed NVTs per host - 2
I found that occurs when GVM runs host_details.nasl script. I’ve tried to limit memory and then got timeout for this task. Before update I didn’t see the same behavior on configured tasks

2 Likes
2

I’ve encountered the same. I changed my cloud instance parameters to figure out how bad it is.
I gave it 32GB RAM and a local SSD for swap to be prepared for the worst.

While the rest of my scan job works fine below 2GB RAM taken, this script starts consuming about 1GB extra per second.
But it doesn’t grow out of bounds. I didn’t see the exact value, but somewhere between 16GB and 32GB it successfully terminates, no swap needed.

I hope no one will consider this to be normal. I could easily run my scan tasks on an 8GB instance before. Now I’m going to need a 32G machine, for just one script at the end.

3

Hello,

and welcome to this community forums.

Please be aware that this is mainly a user based support forum without any guarantee that some one of the development teams is noticing any posting / issues reported within it.

For issues happening after an update it is usually suggested to jump to the issue trackers over at Greenbone · GitHub.

As there hasn’t been any changes on VT / .nasl file side on e.g. host_details.nasl or underlying functions used by it since a few years i would assume there could be a regression introduced in the scanner running it so a detailed report in the follwoing issue tracker would be required:

4

Issue submitted here

1 Like
5

I found a workaround. Edit the scan config to exclude this script. It doesn’t noticeably impact scan results.

Navigate to Configuration > Scan Configs.

  1. Clone “Full and fast” (sheep icon) or whichever scan config is being used.

  2. Edit that clone; append “without host details” to the end of the name.

  3. Under “Edit Network Vulnerability Test Families”, edit “Service detection”. Uncheck “Host Details”. Click “Save”.

  4. Edit the Task to use this new scan config.

Memory utilization is back to normal.

6

Seems this was indeed an issue / regression in the scanner, a fix got prepared by the responsible team in / via:

1 Like
7

Hi there,

thanks for pointing in the right direction. I was just trying to follow informal standards of conducting some basic research, before spamming people with invalid bug reports.

I ended up here and was hoping to get in touch with people who experienced the same, in order to narrow down the issue to something precise enough to be reported.

However, I do these scans once a month and I pull latest containers before that.
I purposely used a smaller instance once again, which should fail scanning if this issue would still be present.

It seems the issue was fixed in the meantime, as more recent replies suggest.

Thanks again.