I corrected this problem for Fedora, and am sure it is also
correct for RHEL.

The problem is that the sh_subshell function was saving pointers
that could change, and when restoring, bad things would happen.

I also added a %with_system_malloc build time option. It
is not enabled by default for the sake of not risking having
it trigger other problems elsewhere, but it was the only way
I managed to get system malloc and valgrind to hint me on the
actual problem.

I did not yet submit the patch upstream (as noted in the spec)
because I could not find a link to a bug report system at
http://www.kornshell.com/

Spec URL: https://pcpa.fedorapeople.org/ksh.spec
SRPM URL: https://pcpa.fedorapeople.org/ksh-20120801-21.fc20.src.rpm

Created attachment 931440 [details]
ksh-20120801-trapcom.patch

To make it a bit easier to verify the problem correction here is
the patch.

The only comment I added:
/* contents of shp->st.st.trapcom may change */
may be a bit misleading, the "bad" save/restore already knows it,
probably I should have added a better description telling that the
data is, usually, modified in code like:

tmp = buf[i]; buf[i] = strdup(tmp); free(tmp);

so the shp->st.st.trapcom needs a a "deep copy", as done in the
patch, to properly save/restore pointers.

I would like to note that the patch should be applied to all products
shipping ksh-20120801.

This was fixed upstream about a year ago. As we are trying to stay close to upstream, to prevent future incompatibilities(and extra work when backporting other fixes in future), we will have to isolate their fix and use that. Please be aware, when you try to fix some bug, always test the latest upstream version first.

Thanks.

Do you have a suggested environment, like an experimental package
source, a git repository, etc, from where to generate the binary?

I can get access to links to downloads. The beta that is
ast-ksh.2014-06-25.tgz is the one with the most recent date
I can find.
When attempting to get access to the gitweb interface I land in
a cgi error page.

Anyway, looking in the related code of the latest beta, the code
itself is still not safe agains't the bug, so I supposed it no
longer trigger the problem (keeping pointers to and reusing or
freeing again already freed pointers) if code that previously was
doing the free/strdup sequence is no longer doing it.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1450.html