Bug 515612

Summary:	Sanity check VG_(realpath) and VG_(readlink) return values
Product:	[Developer tools] valgrind	Reporter:	Mark Wielaard <mark>
Component:	general	Assignee:	Mark Wielaard <mark>
Status:	RESOLVED FIXED
Severity:	normal	CC:	pjfloyd
Priority:	NOR
Version First Reported In:	3.26.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Sanity check VG_(realpath) and VG_(readlink) return values

Description Mark Wielaard 2026-02-06 13:12:30 UTC

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.

Comment 1 Mark Wielaard 2026-02-06 13:25:51 UTC

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.

Comment 2 Paul Floyd 2026-02-06 16:33:15 UTC

OK on FreeBSD 15, illumos latest and macOS 12.

Comment 3 Mark Wielaard 2026-02-06 16:45:38 UTC

(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