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

[arcusbuilds]

This repo vendors github.com/NVIDIA/go-nvlib v0.12.0 (vendor/github.com/NVIDIA/go-nvlib/pkg/nvlib/info/root.go), used from internal/info/auto.go via info.New(...) and nvinfo.ResolvePlatform().

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. Platform and library resolution here can end up pointing at a directory instead of the driver library.

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.

Closed issue: NVIDIA/go-nvlib#107
Merged fix: NVIDIA/go-nvlib#108

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

[tariq1890]

@arcusbuilds Are you encountering the go-nvlib bug in a production environment?

[arcusbuilds]

Not from my own production environment. I found it while reading kubernetes-sigs/dra-driver-nvidia-gpu#1272, a real crash-loop from the same bug in that repo's own copy of the discovery code (fixed there in #1275). That led me to check whether go-nvlib had the same unfixed pattern.