Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Jul 2018 17:42:10 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: mortalfw@...il.com
Subject: Re: overflow() at stdlib.h

* m0rtal f!w <mortalfw@...il.com> [2018-07-12 19:55:56 +0530]:
> Team,
> 
> File: stdlib.h#L:113
> 
> i.e
> char *realpath (const char *__restrict, char *__restrict);
> 
> According to the documentation of realpath() the output buffer needs to be
> at least of size PATH_MAX specifying output buffers large enough to handle
> the maximum-size possible result from path manipulation functions. (In that
> instance, buf's size comes from uv__fs_pathmax_size(). That function
> attempts to use pathconf(path, _PC_PATH_MAX) as noted in the realpath(3)
> docs)
> 

sounds like a portability bug in uv__fs_pathmax_size()

http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html

it should use PATH_MAX if defined or null pointer if not
to be portable to posix conforming targets.

> But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_MAX) is
> used.
> 

where?

> Passing an inadequately-sized output buffer to a path manipulation function
> can result in a buffer overflow. Such functions include realpath()
> readlink() PathAppend() and others.
> 
> Request team to have a look and validate.
> 
> 
> Thank you

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.