FD leak when using the Java DB

[andaaron]

Description

We are importing trivy as a library to scan images hosted in the container image registry we develop, zot.
Trivy is running in zot server side, scanning images from the local the oci layout.
For the most part it is working well, but recently we started scanning images containing Java files.
It looks like every time we scan an image containing Java files, a new file descriptor for trivy-java.db is added, but not closed after the scan is done. The scan is functioning correctly, but it seems like the Java DB is not properly closed.

The code where we are importing an scanning using trivy is at:https://github.com/project-zot/zot/blob/3a9a9327919ff51309269a288ecbd72b550be9d0/pkg/extensions/search/cve/trivy/scanner.go

More specifically setting up the general scan options:
https://github.com/project-zot/zot/blob/3a9a9327919ff51309269a288ecbd72b550be9d0/pkg/extensions/search/cve/trivy/scanner.go#L39

Setting up the input, as a local OCI image in local layout:
https://github.com/project-zot/zot/blob/3a9a9327919ff51309269a288ecbd72b550be9d0/pkg/extensions/search/cve/trivy/scanner.go#L156

Calling the Trivy APIs using the above options as parameters:
https://github.com/project-zot/zot/blob/3a9a9327919ff51309269a288ecbd72b550be9d0/pkg/extensions/search/cve/trivy/scanner.go#L170

Note the Java DB is downloaded in a separate API call, and that calls seems to be OK, no leaking file descriptor for just the download.
The leak seems to be related to the actual scan, or analyzer.
Maybe the sqlite DB is not properly closed after being used?
Note there are no such issues with the other DBs, trivy.db and fanal.db.

Desired Behavior

After the scan is done we shouldn't see a file descriptor open for trivy-java.db.

Actual Behavior

For a very large number of images/scans we can get into this situation

sudo ls -al /proc/$(pidof zot)/fd
[...]
lrwx------ 1 root root 64 Sep 27 18:32 89 -> /data/zot/production/_trivy/java-db/trivy-java.db
lr-x------ 1 root root 64 Sep 27 18:32 9 -> anon_inode:inotify
lrwx------ 1 root root 64 Sep 27 18:32 90 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:32 91 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:37 92 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:37 93 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:37 94 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:37 95 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:37 96 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:37 97 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:37 98 -> /data/zot/production/_trivy/java-db/trivy-java.db
lrwx------ 1 root root 64 Sep 27 18:37 99 -> /data/zot/production/_trivy/java-db/trivy-java.db
sudo ls -al /proc/$(pidof zot)/fd | grep trivy-java | wc -l
316

Reproduction Steps

I mentioned the API calls above. The images in the OCI layout were scanned using the `archiveStandaloneScanner`, basically the code in https://github.com/aquasecurity/trivy/blob/main/pkg/fanal/image/oci.go

Target

Container Image

Scanner

Vulnerability

Output Format

JSON

Mode

Standalone

Debug Output

N/A

Operating System

Ubuntu 20.04.1

Version

github.com/aquasecurity/trivy v0.45.1
github.com/aquasecurity/trivy-db v0.0.0-20230831170347-f732860d4917
github.com/aquasecurity/trivy-java-db v0.0.0-20230209231723-7cddb1406728

Checklist

• Run trivy image --reset
• Read the troubleshooting

[DmitriyLewen]

Hello @andaaron
Thanks for your report!

Created #5272

Regards, Dmitriy

[andaaron]

Thank you @DmitriyLewen, I tested the fix locally, and it's working.

[DmitriyLewen]

Great! Thanks for your feedback.