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@port70.net> wrote:

> * m0rtal f!w <mortalfw@gmail.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
>