Audit required: Possible uncontrolled resource consumption using doublestar.Glob GO-S1047
Be careful when using doublestar.Glob as it internally uses os.Stat, and that does
follow symbolic links (symlinks). In case there's a symlink loop in the filesystem, the
Glob function might result in out-of-memory. Please audit your code for the same. An
attacker might use this vulnerability to their advantage and introduce uncontrolled resource
consumption where file paths gets piled up and leads to process being killed by OOM killer.
As per man path_resolution:
If the component is found and is a symbolic link (symlink), we first resolve this symbolic link (with the current lookup directory as starting lookup directory). Upon error, that error is returned. If the result is not a directory, an ENOTDIR error is returned. If the resolution of the symlink is successful and returns a directory, we set the current lookupdirectory to that directory, and go to the next component. Note that the resolution process here involves recursion. In order to protect the kernel against stack overflow, and also to protect against denial of service, there are limits on the maximum recursion depth, and on the maximum number of symbolic links followed. An ELOOP error is returned when themaximum is exceeded ("Too many levels of symbolic links").
By default, Linux imposes a limit of at most 40 symlinks in any one path lookup.