[PATCH] posix: execvpe: fix UMR with file > NAME_MAX [BZ #33627]

Carlos O'Donell carlos@redhat.com
Mon Nov 17 14:30:03 GMT 2025


On 11/14/25 1:37 PM, Collin Funk wrote:
> Pádraig Brady <P@draigBrady.com> writes:
> 
>> * posix/execvpe.c (__execvpe_common): Since strnlen doesn't inspect
>> beyond NAME_MAX and NAME_MAX does not cover the NUL, we need
>> to explicitly check for the NUL.  I.e. the existing check for,
>> file_len-1 > NAME_MAX, was never true.  This check is required
>> so that we're guaranteed that file_len includes the NUL, as we
>> depend on that in the following memcpy to properly terminate
>> the file buffer passed to execve().  Otherwise that call will trigger
>> UMR when inspecting the passed file, which can be seen with valgrind.
>> Note returning ENAMETOOLONG early here for FILE names > NAME_MAX
>> will also avoid redundant processing of ENAMETOOLONG on each entry
>> in $PATH, after the change in [BZ #33626] is applied.
>> ---
>>   posix/execvpe.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/posix/execvpe.c b/posix/execvpe.c
>> index 0fb09b9631..433b5bb0b3 100644
>> --- a/posix/execvpe.c
>> +++ b/posix/execvpe.c
>> @@ -98,8 +98,9 @@ __execvpe_common (const char *file, char *const argv[], char *const envp[],
>>     size_t file_len = __strnlen (file, NAME_MAX) + 1;
>>     size_t path_len = __strnlen (path, PATH_MAX - 1) + 1;
>>   
>> -  /* NAME_MAX does not include the terminating null character.  */
>> -  if ((file_len - 1 > NAME_MAX)
>> +  /* NAME_MAX does not include the terminating NUL character.
>> +     The following check ensures FILE is NUL terminated.  */
>> +  if ((file_len - 1 == NAME_MAX && file[NAME_MAX] != '\0')
>>         || !__libc_alloca_cutoff (path_len + file_len + 1))
>>       {
>>         errno = ENAMETOOLONG;
> 
> Nice catch. Thanks!
> 
> Reviewed-by: Collin Funk <collin.funk1@gmail.com>

May you please help Padraig get this pushed by committing on their behalf?

-- 
Cheers,
Carlos.



More information about the Libc-alpha mailing list