[PATCH] make getcwd fail if it cannot obtain an absolute path

[PATCH] make getcwd fail if it cannot obtain an absolute path

[Dmitry V. Levin]

Currently getcwd(3) can succeed without returning an absolute path
because the underlying getcwd syscall, starting with linux commit
v2.6.36-rc1~96^2~2, may succeed without returning an absolute path.

This is a conformance issue because "The getcwd() function shall
place an absolute pathname of the current working directory
in the array pointed to by buf, and return buf".

Fix this by checking the path returned by syscall and failing with
ENOENT if the path is not absolute.  The error code is chosen for
consistency with the case when the current directory is unlinked.

Similar issue was fixed in glibc recently, see
https://sourceware.org/bugzilla/show_bug.cgi?id=22679
---
 src/unistd/getcwd.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/unistd/getcwd.c b/src/unistd/getcwd.c
index a7b925d..103fbbb 100644
--- a/src/unistd/getcwd.c
+++ b/src/unistd/getcwd.c
@@ -14,6 +14,12 @@ char *getcwd(char *buf, size_t size)
 		errno = EINVAL;
 		return 0;
 	}
-	if (syscall(SYS_getcwd, buf, size) < 0) return 0;
+	long ret = syscall(SYS_getcwd, buf, size);
+	if (ret < 0)
+		return 0;
+	if (ret == 0 || buf[0] != '/') {
+		errno = ENOENT;
+		return 0;
+	}
 	return buf == tmp ? strdup(buf) : buf;
 }
-- 
ldv

Re: [PATCH] make getcwd fail if it cannot obtain an absolute path

[Rich Felker]

On Fri, Jan 12, 2018 at 06:12:24PM +0300, Dmitry V. Levin wrote:
> Currently getcwd(3) can succeed without returning an absolute path
> because the underlying getcwd syscall, starting with linux commit
> v2.6.36-rc1~96^2~2, may succeed without returning an absolute path.
> 
> This is a conformance issue because "The getcwd() function shall
> place an absolute pathname of the current working directory
> in the array pointed to by buf, and return buf".
> 
> Fix this by checking the path returned by syscall and failing with
> ENOENT if the path is not absolute.  The error code is chosen for
> consistency with the case when the current directory is unlinked.
> 
> Similar issue was fixed in glibc recently, see
> https://sourceware.org/bugzilla/show_bug.cgi?id=22679
> ---
>  src/unistd/getcwd.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/src/unistd/getcwd.c b/src/unistd/getcwd.c
> index a7b925d..103fbbb 100644
> --- a/src/unistd/getcwd.c
> +++ b/src/unistd/getcwd.c
> @@ -14,6 +14,12 @@ char *getcwd(char *buf, size_t size)
>  		errno = EINVAL;
>  		return 0;
>  	}
> -	if (syscall(SYS_getcwd, buf, size) < 0) return 0;
> +	long ret = syscall(SYS_getcwd, buf, size);
> +	if (ret < 0)
> +		return 0;
> +	if (ret == 0 || buf[0] != '/') {
> +		errno = ENOENT;
> +		return 0;
> +	}
>  	return buf == tmp ? strdup(buf) : buf;
>  }
> -- 
> ldv

Looks ok. Can you provide any details on the circumstances under which
the kernel bug manifests? This would help users who may be affected
assess the severity of the situation.

Rich

Re: [PATCH] make getcwd fail if it cannot obtain an absolute path

[Rich Felker]

On Fri, Jan 12, 2018 at 02:29:27PM -0500, Rich Felker wrote:
> On Fri, Jan 12, 2018 at 06:12:24PM +0300, Dmitry V. Levin wrote:
> > Currently getcwd(3) can succeed without returning an absolute path
> > because the underlying getcwd syscall, starting with linux commit
> > v2.6.36-rc1~96^2~2, may succeed without returning an absolute path.
> > 
> > This is a conformance issue because "The getcwd() function shall
> > place an absolute pathname of the current working directory
> > in the array pointed to by buf, and return buf".
> > 
> > Fix this by checking the path returned by syscall and failing with
> > ENOENT if the path is not absolute.  The error code is chosen for
> > consistency with the case when the current directory is unlinked.
> > 
> > Similar issue was fixed in glibc recently, see
> > https://sourceware.org/bugzilla/show_bug.cgi?id=22679
> > ---
> >  src/unistd/getcwd.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/unistd/getcwd.c b/src/unistd/getcwd.c
> > index a7b925d..103fbbb 100644
> > --- a/src/unistd/getcwd.c
> > +++ b/src/unistd/getcwd.c
> > @@ -14,6 +14,12 @@ char *getcwd(char *buf, size_t size)
> >  		errno = EINVAL;
> >  		return 0;
> >  	}
> > -	if (syscall(SYS_getcwd, buf, size) < 0) return 0;
> > +	long ret = syscall(SYS_getcwd, buf, size);
> > +	if (ret < 0)
> > +		return 0;
> > +	if (ret == 0 || buf[0] != '/') {
> > +		errno = ENOENT;
> > +		return 0;
> > +	}
> >  	return buf == tmp ? strdup(buf) : buf;
> >  }
> > -- 
> > ldv
> 
> Looks ok. Can you provide any details on the circumstances under which
> the kernel bug manifests? This would help users who may be affected
> assess the severity of the situation.

Ah, this answers it:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=v2.6.36-rc1~96%5e2~2

So it seems to be things like a no-longer-reachable working directory
after chroot or in a container.

Rich