You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Terraform: concurrent scans race on the module cache, so a module can be dropped or read half-written
#11591
remoteResolver.download (pkg/iac/scanners/terraform/parser/resolvers/remote.go) writes a remote Terraform module directly into its cache path, <tmp>/.aqua/cache/<key>, after os.RemoveAll(dst), with no lock and no rename. Two Trivy processes that need the same uncached module work on the same directory at once, and at least one usually loses the module. The cache is under the system temporary directory, so any two scans on one machine share it, such as parallel jobs on a CI runner.
The scan still exits 0 and reports nothing from the module. Most times it logs Failed to load module. Sometimes a process finds the directory while the other is still writing it: its debug log says Module resolved from cache, no error is logged, and the module contributes no findings. That happened in 4 of 40 runs of a wrapper tool that starts both processes, and it cannot be told from a clean result.
Desired Behavior
Each process gets the whole module, or a clear failure. Downloading into a temporary directory beside the cache path and renaming it into place when complete would do it: a reader then sees a finished module or none, and two downloaders cannot clobber each other.
Actual Behavior
Findings per directory over ten rounds, each with a new empty TMPDIR:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Description
remoteResolver.download(pkg/iac/scanners/terraform/parser/resolvers/remote.go) writes a remote Terraform module directly into its cache path,<tmp>/.aqua/cache/<key>, afteros.RemoveAll(dst), with no lock and no rename. Two Trivy processes that need the same uncached module work on the same directory at once, and at least one usually loses the module. The cache is under the system temporary directory, so any two scans on one machine share it, such as parallel jobs on a CI runner.The scan still exits 0 and reports nothing from the module. Most times it logs
Failed to load module. Sometimes a process finds the directory while the other is still writing it: its debug log saysModule resolved from cache, no error is logged, and the module contributes no findings. That happened in 4 of 40 runs of a wrapper tool that starts both processes, and it cannot be told from a clean result.Desired Behavior
Each process gets the whole module, or a clear failure. Downloading into a temporary directory beside the cache path and renaming it into place when complete would do it: a reader then sees a finished module or none, and two downloaders cannot clobber each other.
Actual Behavior
Findings per directory over ten rounds, each with a new empty
TMPDIR:Run one after the other, each directory reports 48 every time.
Reproduction Steps
Target
Filesystem
Scanner
Misconfiguration
Output Format
JSON
Mode
Standalone
Debug Output
Operating System
Ubuntu 24.04.5 LTS
Version
Checklist
The reproduction starts from an empty
TMPDIR, where the module cache lives, sotrivy clean --alldoes not bear on it, and it was not run.All reactions