Created attachment 932743 [details]
This patch partially corrects the problem

ksh has the src/cmd/ksh93/sh/path.c:path_pwd() function that is used to
compute the current directory from different contexts. The function receives
a boolean flag argument that is useful to avoid a getcwd call, and (re)set
the $PWD variable contents (the PWDNOD "object").

  Regardless of the flag argument, if shp->pwd (a "cached" char* known value
of the current directory) is non null, path_pwd() returns it.

  If shp->pwd is null, path_pwd() will enter a loop, and try to resolve the
current path. It will loop up to six times, attempting to avoid a getcwd
call (maybe because it may be too costly in some environment/filesystem)
and/or attempting to avoid the need of change to the PWDNOD value. The loop
is essentially:

	while(1) 
	{
		/* try from lowest to highest */
		switch(count++)
		{
			case 0:
				cp = nv_getval(PWDNOD);
				break;
			case 1:
				cp = nv_getval(HOME);
				break;
			case 2:
				cp = "/";
				break;
			case 3:
				cp = (char*)e_crondir;
				if(flag) /* skip next case when non-zero flag */
					++count;
				break;
			case 4:
			{
				if(cp=getcwd(NIL(char*),0))
				{  
					nv_offattr(PWDNOD,NV_NOFREE);
					nv_unset(PWDNOD);
					PWDNOD->nvalue.cp = cp;
					goto skip;
				}
				break;
			}
			case 5:
				return(dfault);
		}
		if(cp && *cp=='/' && test_inode(cp,e_dot))
			break;
	}

   I believe case 3 is history, at least for modern Linux systems, as
it is a hardcoded test of the current directory as /usr/spool/cron/atjobs
that is very likely to always fail. It will only break the loop if
the directory in the cp string pointer has the same stat st_dev and st_ino
as ".". If it loops the six times, it will return ".", that is the
initialized value of "dfault".

  A problem arises here if a C program calls chdir() and then exec*()
ksh, because in that case, (unless doing the noop of chdir()'ing to the
$PWD value), $PWD and "." will not match, it will loop the six times and
return "." as the current directory if receiving a non zero flag (kind
of "fast mode").

  The path_pwd() function is called with a non zero flag argument
during initialization, and only on a few cases will be called with
a zero flag argument, notably when executing a subshell.

  I believe it should be quite safe to remove "case 3" and adjust
the code. Maybe even the flag argument could be ignored, but would
need to check if calling getcwd on a stale nfs could hang, etc,
but that would be the best to ensure path_pwd() actually does what
it advertises (unless shp->pwd somehow is set to a bad value), the
contents of $PWD would always match the current directory; either
the test_inode would validate special values are the same directory,
or call getcwd.

  Nevertheless lets assume we do not want to ignore the flag argument,
because there must be a reason to avoid the getcwd call (possibly a
stale nfs mount, current directory on a tape, etc). *If* if any
*non* builtin command is executed *after* any builtin "cd" call,
(or the builtin "pwd" command is executed, because it calls
path_pwd() with a zero flag) it will call path_pwd() with a zero flag
argument eventually, that would call getcwd() and correct the internal
state. So, my proposed patch is specific to ksh-2012-08-01, because
ksh-2010-06-21 as in earlier rhel is not affected by this issue at least
for the provided test case, but has code quite different, and latest beta,
2014-06-25 also has the code quite different, and *may* not show the
problem, but it was not verified, only base code inspection was done.
So, the patch basically detects the condition where it would get confused,
and corrects it just before the inconsistency happens, that is, while the
input says something like:
	cd ..
ksh would understand it as
	cd .
and do nothing.