vendored go-nvlib is affected by tryResolveLibrary directory-shadowing bug (NVIDIA/go-nvlib#107) #1945

This repo vendors github.com/NVIDIA/go-nvlib v0.12.0 (vendor/github.com/NVIDIA/go-nvlib/pkg/nvlib/info/root.go), pulled in both directly and through github.com/NVIDIA/nvidia-container-toolkit/pkg/nvcdi, and used from internal/rm, internal/plugin, internal/resource, and the plugin, gfd, and mps-control-daemon entrypoints.

That version has the bug from NVIDIA/go-nvlib#107: tryResolveLibrary resolves each candidate path with filepath.EvalSymlinks but never checks whether the result is a regular file. EvalSymlinks succeeds for directories too, so a stray directory named after a library in an earlier search path, for example /usr/lib64/libnvidia-ml.so.1, shadows the real library found later under /usr/lib/x86_64-linux-gnu. Driver library discovery here can end up pointing at a directory instead of the real .so.

The fix ("Skip non-regular files in tryResolveLibrary") is merged in NVIDIA/go-nvlib#108, but go-nvlib hasn't tagged a release past v0.12.0, so a normal go get -u won't pick it up yet.

Once go-nvlib cuts a release with #108 in it, or if a pseudo-version pin to the merge commit a9dc4f8 works as a stopgap, this repo's go.mod and vendor tree need the bump. nvidia-container-toolkit vendors the same broken copy directly (filed as NVIDIA/nvidia-container-toolkit#1966), and this repo pulls it in a second time through that module.

Closed issue: NVIDIA/go-nvlib#107
Merged fix: NVIDIA/go-nvlib#108
Same issue in nvidia-container-toolkit: NVIDIA/nvidia-container-toolkit#1966

I can open the dependency bump PR once a release or pseudo-version is agreed on.