nasl_pread: Failed to close file descriptor (only on certain systems)

[LoZio]

** Please attach large files to the report instead of pasting the contents into the report. **

Describe the bug
Installed latest container as of today. Log says it's
Greenbone Vulnerability Manager version 23.1.0 (DB revision 255)
First I upgraded the existing data using the volume I had before, then I created a brand new volume and container and started from scratch.
I create a target or use one of the dozens I have and have always used.
I start a scan using full and fast config, but it is the same with any of my configurations I always used.
The only data that the scanner gets is the ping result. None of the test in the scan config is performed.
If I look at the processes that run during the scan the usual ones do not even start.
The reports says 0 ports are available.
If I tcpdump the interface I see the ICMP traffic but nothing about tcp ports.
It seems nmap does not start at all, so no test are performed on the 0 open ports.
If I start a bash in the container and manually run nmap on the same IPs I want to scan it works with no problems (shows the open ports on targets, so network is also checked ok) and I can sniff the tcp probes.
In the logs nothing says it failed, for example it reports:

OSPD[683] 2024-01-08 16:44:56,433: INFO: (ospd.ospd) Starting scan 7e21607b-640a-4751-a6f6-15dfeff8f5d1.
OSPD[683] 2024-01-08 16:46:37,685: INFO: (ospd.ospd) 7e21607b-640a-4751-a6f6-15dfeff8f5d1: Host scan finished.
OSPD[683] 2024-01-08 16:46:37,692: INFO: (ospd.ospd) 7e21607b-640a-4751-a6f6-15dfeff8f5d1: Scan finished.

I changed any of the alive tests, always does the same thing, stops the scan after the ping phase.

To Reproduce
Steps to reproduce the behavior:
Just used docker start with :latest image.
Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Environment (please complete the following information):

• OS: Ubuntu 22.04
• Memory available to OS: 18G
• Container environment used with version:
  Client: Docker Engine - Community
  Version: 24.0.7
  API version: 1.43
  Go version: go1.20.10
  Git commit: afdd53b
  Built: Thu Oct 26 09:08:01 2023
  OS/Arch: linux/amd64
  Context: default

Server: Docker Engine - Community
Engine:
Version: 24.0.7
API version: 1.43 (minimum version 1.12)
Go version: go1.20.10
Git commit: 311b9ff
Built: Thu Oct 26 09:08:01 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.26
GitCommit: 3dd1e886e55dd695541fdcd67420c2888645a495
runc:
Version: 1.1.10
GitCommit: v1.1.10-0-g18a0cb0
docker-init:
Version: 0.19.0
GitCommit: de40ad0

logs ( commands assume the container name is 'openvas' )
Please attach the output from one of the following commands:

docker

docker logs openvas > logfile.log

Podman

podman logs openvas > logfile.log

docker-compose

docker-compose logs > logfile.log

Please "attach" the file instead of pasting the conents to the issue.

[immauss]

Is the container showing as healthy?

-Scott

[LoZio]

Yes, and it is actually healthy since it all works, also reports are being generated. It just seem not to start the nmap so there are no ports to scan.

[immauss]

Can you run a scan against this container:
immauss/scannable

use:
User: scannable
password: Passw0rd

Just fire it up, check the logs for its IP, and then create a target for it.

might even be easier to use the docker-compose.yml that is in the "testing" directory. It will start a scannable container on the same network.

[LoZio]

Did a clean setup of everithing. New openvas:latest container from scratch, updated.
Started a scannable container (got 172.17.0.3 ip). I can login via ssh to the scannable from the openvas

So the docker openvas can reach the ssh of the scannable instance.

I create a new target for 172.17.0.3. I create a new scan with full and fast profile
The profile has all the things

Still the scan task terminates with no problems, only finding the icmp result and no errors

[immauss]

Curious ... what port list are you assigning to the target?

-Scott

[LoZio]

I also tested a set with only ssh, nothing changes. Changed the alive test to ping. Same.
If I sniff on the target (one of mine) I see the icmp probes coming, no tcp probes coming.
If I enter the openvas container and start an nmap to the machine where I'm sniffing, I see the nmap SYNs.

[immauss]

I'm stumped ....
I have that same version scanning hosts on multiple installs ....

If you roll back to a previous version, 22.4.37 or 22.4.36, does the problem persist?

-Scott

[LoZio]

I tried 22.4.36 before writing this post, same behavior (and still have the container if needed for tests) and :latest on a different host (physical), same odd behavior

[immauss]

Was 22.4.36 working for you previously?

.38 was a big change since I moved to a new base image, which was my concern...

-Scott

[LoZio]

I did my last upgrade at the beginning of december using :latest as I usually do, and did a scan with no problem. Then after the holidays I upgraded to latest .37. I don't know which was the last version that worked. If you give me the tag for a pre-big-changes version I'll run a new dedicated container later in the afternoon. I'll use the same host to avoid changing too many things together

[immauss]

Hmmm .38 should have been the most recent "big" change.
But....

.35 was pushed on 22 November with .34 only existing briefly. So maybe go all the way back to .33 ?
Most of the changes in there were minor version updates from GB and some changes with the timeouts for the healthcheck script.

-Scott

[LoZio]

Launched a .33 container and it works as always did!

.33 is good!
Edit: I'm running a sync just to check that there's noting related to NVTs or something, then re-launch the scan

[immauss]

Well ...
That is odd .....
But now I know where to look.
Thanks.

Let me know how it goes after the sync, because you are right, that could have an effect was well.

-Scott

[LoZio]

Second scan after feed sync was good, ports found open.