Date: Thu, 12 Jul 2018 21:21:38 +0530 From: Dhiraj <mortalfw@...il.com> To: musl@...ts.openwall.com, "m0rtal f!w" <mortalfw@...il.com> Subject: Re: overflow() at stdlib.h Thanks Szabolcs for taking look into this, > But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_MAX) is > used. > > where? In stdlib.h file. However, we can allocate a "PATH_MAX + 1" or POSIX.1-2008 would allow us to pass in a NULL poiter and have realpath allocating enough memory. Regards Dhiraj On Thu, Jul 12, 2018 at 9:12 PM, Szabolcs Nagy <nsz@...t70.net> wrote: > * 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 > Content of type "text/html" skipped
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.