From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13028 Path: news.gmane.org!.POSTED!not-for-mail From: Dhiraj Newsgroups: gmane.linux.lib.musl.general Subject: Re: overflow() at stdlib.h Date: Thu, 12 Jul 2018 22:05:36 +0530 Message-ID: References: <20180712154209.GJ4418@port70.net> <20180712163057.GK4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000042ed7e0570cff459" X-Trace: blaine.gmane.org 1531413230 18756 195.159.176.226 (12 Jul 2018 16:33:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jul 2018 16:33:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-13044-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 12 18:33:46 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fdeXJ-0004m9-FI for gllmg-musl@m.gmane.org; Thu, 12 Jul 2018 18:33:45 +0200 Original-Received: (qmail 16146 invoked by uid 550); 12 Jul 2018 16:35:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16128 invoked from network); 12 Jul 2018 16:35:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oQeIlOTzxt5crfoO4jfhXOZ7BWY9uaPKB1q5aPBlOhs=; b=B8kwHrd1AO40VkEV0GRTvZfXhai8kVgYPIhZUPjaHOT+o+mg/WauOg3qqlBzU9Atn8 hr1sXf3SY4Tvm61eC0/9Fd5ihmNcK5jqt5sn7F1xuvcKjqzauMymx5kl5XsModme9ukU HaBEe698MEq+XT73rDOau5aw17QvYXipNgpMI7jgpaN52qqrzxvTNikvHesNYE7CpteH y19xaE4YuvbigHvZM7IG5xZdndV4ZwCxKEshK3VU4sha0GAndLO3FPQ0NjHQLgvRjDbt sAPIAwRQf82JuBqZjn8cBvOLPC8AKjtsgCjifdmkVOsS0UQEDCe46quGF7vdY0aJnKjD TV0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oQeIlOTzxt5crfoO4jfhXOZ7BWY9uaPKB1q5aPBlOhs=; b=U7aNkYjeM+MRjcUobt1SvyVVCT6uTjOvqPXa7oTAqos5tPTSjSp48e8+X5FVjg1svy 7LjXxSVqwsVaArVA16nb0ZgR3bisTk/ZXpHTsbJphS62Fjn/QoMeGg62YTk9euTn6082 ZJ35jUop+T8DWgFK0evapbqPZKd5e766QAEBWIDayAeWV616R9Tfcb8vofR2/ZQT6gYz rfmYzwfN39Zbr/Yg5MSRyThaSqo6sIbryzJ8Olh7fFlgk7EC/qrvlU1r4q1FJfo/v6KN hoBZvXdwpL1FUZYh4n0IibaiwK9lvkPTUHMkGFMb0S1thMqFzsTF7fN8UlLD66YOSrpd unvA== X-Gm-Message-State: AOUpUlH03Ta136gJCvTBRH6AxFJAWkU/LTve8x0tRgsYbbipEN9wM2Jh CQoSRuz2YUxFZ0aENWEZHww0HmprRisqHudpAO6vaTGv X-Google-Smtp-Source: AAOMgpf13hJCo+rgllviEOnc9qpueyXb7Q/R7QToFXNWqCVxof+KxSw7T+Y278+7QqOMF0uwOJlG7F1N5h36mc7H2ag= X-Received: by 2002:adf:9405:: with SMTP id 5-v6mr1237914wrq.129.1531413342120; Thu, 12 Jul 2018 09:35:42 -0700 (PDT) In-Reply-To: <20180712163057.GK4418@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:13028 Archived-At: --00000000000042ed7e0570cff459 Content-Type: text/plain; charset="UTF-8" Reference: http://man7.org/linux/man-pages/man3/realpath.3.html or as you suggested it might be a portability bug. /D On Thu 12 Jul, 2018 10:00 pm Szabolcs Nagy, wrote: > * Dhiraj [2018-07-12 21:21:38 +0530]: > > 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. > > > > i don't understand what is the issue. > > > 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. > > > > why +1? > > PATH_MAX is the maximum amount of bytes realpath may write (i.e. it > includes > the terminating nul byte). > > > On Thu, Jul 12, 2018 at 9:12 PM, Szabolcs Nagy wrote: > > > * m0rtal f!w [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 > > > > --00000000000042ed7e0570cff459 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

or as you sug= gested it might be a portability bug.




<= /div>
/D

On Thu 12 Jul, 2018 10:00 pm Szabolcs Nagy, <nsz@port70.net> wrote:
* Dhiraj <mortalfw@gmail.com> [2018-07-12 21:21= :38 +0530]:
> Thanks Szabolcs for taking look into this,
>
> > But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_M= AX) is
> > used.
> >
>
> > where?
>
> In stdlib.h file.
>

i don't understand what is the issue.

> However, we can allocate a "PATH_MAX + 1" or POSIX.1-2008 wo= uld allow us to
> pass in a NULL poiter and have realpath allocating enough memory.
>

why +1?

PATH_MAX is the maximum amount of bytes realpath may write (i.e. it include= s
the terminating nul byte).

> 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 buff= er needs to
> > be
> > > at least of size PATH_MAX specifying output buffers large en= ough to
> > handle
> > > the maximum-size possible result from path manipulation func= tions. (In
> > that
> > > instance, buf's size comes from uv__fs_pathmax_size(). T= hat 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://p= ubs.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_P= ATH_MAX) is
> > > used.
> > >
> >
> > where?
> >
> > > Passing an inadequately-sized output buffer to a path manipu= lation
> > function
> > > can result in a buffer overflow. Such functions include real= path()
> > > readlink() PathAppend() and others.
> > >
> > > Request team to have a look and validate.
> > >
> > >
> > > Thank you
> >
--00000000000042ed7e0570cff459--