There are a couple of places in the code where the result of VG_(realpath) or VG_(readlink) isn't being checked. This could potentially cause some array underflow writes (to array[-1]) and/or the use of undefined (stack) memory. In one case an overly long path could write beyond a temporary buffer. All these cases are probably very unlikely to be hit, but could cause errors or warnings from valgrind to be garbled.
Created attachment 189275 [details] Sanity check VG_(realpath) and VG_(readlink) return values Patch tested on GNU/Linux setup. Would be nice if someone could double check it works as expected on Solaris, Darwin and FreeBSD.
OK on FreeBSD 15, illumos latest and macOS 12.
(In reply to Paul Floyd from comment #2) > OK on FreeBSD 15, illumos latest and macOS 12. Thanks for testing. Pushed as: commit 6a0735f3eaf12397814267c6f9a9aada36418f96 Author: Mark Wielaard <mark@klomp.org> Date: Fri Feb 6 13:57:24 2026 +0100 Sanity check VG_(realpath) and VG_(readlink) return values When VG_(realpath) calls VG_(readlink) it failed to check if VG_(readlink) succeeds, possibly writing to tmp[-1] (on the stack). It also didn't check the getcwd syscall succeeded, which would cause the resolved name to start with undefined bits (from the stack). VG_(data_size) was using too small a (stack) buffer for the VG_(realpath) call and didn't check whether the call actually succeeded. At startup initimg-{darwin,freebsd,linux,solaris} also didn't check VG_(realpath) would resolve before setting VG_(resolved_exename) to possibly random bits on the stack. Fix that by using the (unresolved) exe_name in those cases. https://bugs.kde.org/show_bug.cgi?id=515612